Subject: atom:link rel="printer-friendly" ??

From: "John R. Frank" <[email-masked]>
Date: Tue, 16 Sep 2008 15:13:24 -0400 (EDT)

atom-syntax,

We're working with several news paper web sites who want to provide both
an "official" URL and also a means of accessing a "printer-friendly" or
"de-chromed" version of the content associated with that URL.

Is there an established technique for representing this in Atom?

Should it be an atom:link element with a special rel="" attribute?

Or should we use atom:content to include the printer-friendly version in
the feed itself?

Or something else?

Please forgive me if this is documented somewhere and I just didn't search
hard enough yet.

Thanks for your help.

John

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Sep 2008 21:25:39 +0200

John R. Frank wrote:
> ...

Isn't that done through CSS nowadays?

BR, Julian

---

From: "John R. Frank" <[email-masked]>
Date: Tue, 16 Sep 2008 15:37:38 -0400 (EDT)

> > We're working with several news paper web sites who want to provide
> > both an "official" URL and also a means of accessing a
> > "printer-friendly" or "de-chromed" version of the content associated
> > with that URL. ...
>

While that is useful, it requires that the downstream process parse the
HTML and apply the CSS to identify which page elements are not part of the
printer-friendly version.

That's more complicated than providing a separate means of accessing the
so-called "body" content, so we're trying to figure out how best to
describe that separate copy in Atom.

John

---

From: Tim Bray <[email-masked]>
Date: Tue, 16 Sep 2008 12:46:54 -0700

On Sep 16, 2008, at 12:13 PM, John R. Frank wrote:

> both

<link rel="printer-friendly" ...

seems perfectly sensible to me.    -Tim

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Tue, 16 Sep 2008 22:34:38 +0200

Hi John,

* John R. Frank <[email-masked]> [2008-09-16 21:25]:
> Please forgive me if this is documented somewhere

it’s not.

> We're working with several news paper web sites who want to
> provide both an "official" URL and also a means of accessing a
> "printer-friendly" or "de-chromed" version of the content
> associated with that URL.

What is your goal with this feature?

From a purely theoretical perspective, the printer-friendly
version is just another alternate representation of the same
resource, for which Atom already provides a link relation –
makes it the default one, even. (And an Entry can have any number
of alternate links.) If you give it a title like “Print Version”,
a human would know which one to pick.

But if your aim is to allow readers to print stories, your very
best bet by a long shot is to include a small “Printable version”
link inside the summary or full-text of an entry. Another option
that you may take either in addition or by itself is to include
the link to the printer-friendly version with `rel="related"`.
Many aggregators do not display these links, but quite a few
will. It is highly doubtful whether any of them will be able to
do something useful when faced with an Entry that has multiple
alternate links. It is, OTOH, not doubtful at all that absolutely
none of them will display a `rel="printer-friendly"` link.

However, if enabling automatic processing (such as letting people
write scripts to pull the feed and print all of the entries as a
kind of personal newspaper, or whatever) is a consideration,
then providing such a `rel="printer-friendly"` link is pretty
much imperative. It won’t help human readers with aggregators at
all, though, as I already mentioned.

Note that these options are not exclusive. You could include two
or three links to the same URI but with different `rel` values,
in order to address different kinds of feed processors.

As for atom:content, what do you *currently* have in there? In
general, content published in feeds should avoid any sort of
chrome anyway – since the content gets rendered in a big variety
of display contexts, it will be more widely useful the more
purely semantical and non-presentational it is. So depending on
circumstances the answer to your question may really be to simply
stick the printer-friendly content in atom:content and not worry
about including special link.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "John R. Frank" <[email-masked]>
Date: Tue, 16 Sep 2008 16:50:00 -0400 (EDT)

> However, if enabling automatic processing (such as letting people write
> scripts to pull the feed and print all of the entries as a kind of
> personal newspaper, or whatever) is a consideration,

Yes, that's the main goal.

> As for atom:content, what do you *currently* have in there? In general,
> content published in feeds should avoid any sort of chrome anyway –
> since the content gets rendered in a big variety of display contexts, it
> will be more widely useful the more purely semantical and
> non-presentational it is. So depending on circumstances the answer to
> your question may really be to simply stick the printer-friendly content
> in atom:content and not worry about including special link.

Yes, this is what we're thinking is the best approach, beucase it jives
with what appears to be the original intent of atom:content

Thank you all for your help.

Yours,
John

---

From: "Brian Smith" <[email-masked]>
Date: Thu, 18 Sep 2008 01:37:10 -0500

Aristotle Pagaltzis wrote:
> resource, for which Atom already provides a link relation - 
> makes it the default one, even. (And an Entry can have any 
> number of alternate links.) If you give it a title like 
> "Print Version", a human would know which one to pick.

An entry can have any number of alternate links, but it can only have one of
each MIME type (for any given human language). If you already have an
alternate text/html link for the non-printer-friendly HTML encoding, then
you are not allowed to have any additional alternate text/html
representation. 

(I completely agree with everything else Aristotle had to say.)

- Brian

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Thu, 18 Sep 2008 12:49:14 +0200

> you are not allowed to have any additional alternate text/html
Brian,

May I ask where this is specified in RFC 4287? I cannot find any such 
restriction.

- Sylvain

---

From: James Aylett <[email-masked]>
Date: Thu, 18 Sep 2008 12:11:01 +0100

On Thu, Sep 18, 2008 at 12:49:14PM +0200, Sylvain Hellegouarch wrote:

> >An entry can have any number of alternate links, but it can only have one 
> >of each MIME type (for any given human language).
> 

4.1.1, bullet point 9.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: Colm Divilly <[email-masked]>
Date: Thu, 18 Sep 2008 12:16:04 +0100

> May I ask where this is specified in RFC 4287? I cannot find any such 
4.1.2 bullet 7:

atom:entry elements MUST NOT contain more than one atom:link
      element with a rel attribute value of "alternate" that has the
      same combination of type and hreflang attribute values.

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Thu, 18 Sep 2008 14:58:50 +0200 (CEST)

>       same combination of type and hreflang attribute values.

Thanks. I was looking at the atom:link section and I didn't think about
the atom:entry one.

- Sylvain
-- 
Sylvain Hellegouarch
http://www.defuze.org

---

From: "'Aristotle Pagaltzis'" <[email-masked]>
Date: Thu, 18 Sep 2008 14:56:39 +0200

* Brian Smith <[email-masked]> [2008-09-18 08:50]:
> An entry can have any number of alternate links, but it can
> only have one of each MIME type (for any given human language).

Yes, I overlooked that. my bad.

I do have to wonder in retrospect why we thought a resource could
not have several different equally valid representations with the
same content type, but that ship has long sailed.

Regards,

---

From: Julian Reschke <[email-masked]>
Date: Thu, 18 Sep 2008 15:28:27 +0200

> same content type, but that ship has long sailed.

It has sailed RFC-wise, but not erratum-wise.

If we have consensus this is a bug (is it?), then we should add it to 
the currently empty list at 
<http://www.rfc-editor.org/errata_search.php?rfc=4287>.

BR, Julian

---

From: Eric Scheid <[email-masked]>
Date: Thu, 18 Sep 2008 23:51:26 +1000

> same content type, but that ship has long sailed.

think of it as subtle incentive to mint more specific and appropriate @rel
values =)

e.

---

From: "DeWitt Clinton" <[email-masked]>
Date: Thu, 18 Sep 2008 07:28:10 -0700

> think of it as subtle incentive to mint more specific and appropriate @rel

Setting the question of "more and appropriate @rel values" aside, why prefer
rel="printer-friendly" over rel="print"?

I.e., if people really do want to go there, why not at least stay consistent
with the HTML4/CSS2 media naming conventions?

  http://www.w3.org/TR/html4/types.html#h-6.13
  http://www.w3.org/TR/CSS2/media.html

But instead of changing the rel value away from the perfectly reasonable
"alternate", why not just add @media to the link?

<link rel="alternate"
      media="print"
      type="text/html"
      href="http://www.xml.com/?print=1"/>

This is also where HTML5 is headed:

  http://www.w3.org/html/wg/html5/#the-link

-DeWitt

---

From: Julian Reschke <[email-masked]>
Date: Thu, 18 Sep 2008 16:46:02 +0200

>       href="http://www.xml.com/?print=1"/>

Sounds good.

>   http://www.w3.org/html/wg/html5/#the-link

Actually, this was already in HTML 4: 
<http://www.w3.org/TR/html4/struct/links.html#edef-LINK>.

BR, Julian

---

From: "Tatsuhiko Miyagawa" <[email-masked]>
Date: Thu, 18 Sep 2008 23:47:38 +0900

>   http://www.w3.org/html/wg/html5/#the-link

A while ago we discussed with people from mobile content publisher and
aggregator to make a standard to embed links to mobile optimized page
in XHTML, RSS and Atom. We named it Mobile Link Discovery and its
XHTML version is currently widely used including Google mobile search
engine.
http://www.sixapart.jp/docs/tech/mobile_link_discovery_en.html

This uses XHTML's standard link rel="alternate" tags with
media="handheld" attribute set. I guess using rel="print" here would
do the same thing to embed links to printer friendly links. Our spec
was focused on XHTML version and included a draft suggestion about
doing the same with <atom:link> but it turned out some feed parsers
just got confused with multiple atom:link rel="alternate" (and also
could be invalid if there are multiple links with the same MIME type
which we weren't aware at the time) and hence hasn't been widely used.

-- 
Tatsuhiko Miyagawa

---

From: "Brian Smith" <[email-masked]>
Date: Thu, 18 Sep 2008 10:09:10 -0500

DeWitt Clinton  wrote: 
> But instead of changing the rel value away
> from the perfectly reasonable "alternate",
> why not just add @media to the link?
>	
>	<link rel="alternate"
>	      media="print"
>	      type="text/html"
	
@media is an excellent idea. However, it doesn't overcome the restriction
that you can only have one text/html alternate link, so you would still need
a different link relation.

- Brian

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Thu, 18 Sep 2008 20:17:00 +0200

* Eric Scheid <[email-masked]> [2008-09-18 16:00]:
> > I do have to wonder in retrospect why we thought a resource
> > could not have several different equally valid
> > representations with the same content type, but that ship has
> > long sailed.
> 
> think of it as subtle incentive to mint more specific and
> appropriate @rel values =)

That is a good point. If it were allowed, the fact that
aggregators privilege `alternate` links might have led
people to declare resources as alternates that aren’t.

(Linkblogs do just that, but that’s another windmill…)

Ugh.

(Note that speaking both in a pure semantic sense and in a
pragmatic sense, for this particular use case I really do
consider `alternate` to be the appriopriate relation.)

Regards,

---

From: Antone Roundy <[email-masked]>
Date: Thu, 18 Sep 2008 13:40:42 -0500

> consider `alternate` to be the appriopriate relation.)

The reason I disagree with this is that the value of @type doesn't 
convey the fact that the link points to a printer-friendly alternative. 
  If you could do something like 'type="text/html;media=print"', then 
sure, but without information like that, there's no way to automatically 
select the appropriate alterative representation for a particular use.

---

From: "Ross Singer" <[email-masked]>
Date: Fri, 19 Sep 2008 09:53:45 -0400

On Thu, Sep 18, 2008 at 2:40 PM, Antone Roundy <[email-masked]> wrote:
>
> The reason I disagree with this is that the value of @type doesn't convey
> the fact that the link points to a printer-friendly alternative.  If you
> could do something like 'type="text/html;media=print"', then sure, but
> without information like that, there's no way to automatically select the
> appropriate alterative representation for a particular use.
>

My interpretation of the spec is that having two alternate tags with
the types: text/html and text/html;media=print is completely legal.
Is that correct?  If so, is this a case where it might be helpful to
establish best practices for content-type parameters?

It seems like this would be immensely beneficial for application/xml
(or any of the other catch-all mime-types for a vast variety of data
types) to have a semi-standardized way to define or request the
contents of an entry:content tag (or whatever).

While I think it's somewhat out of scope for Atom to define that
(since we're talking about link relationships, so that could be
*anything*), if this was useful, it could be used to establish
conventions within specific communities.

-Ross.

---

From: Antone Roundy <[email-masked]>
Date: Fri, 19 Sep 2008 10:35:49 -0500

> establish best practices for content-type parameters?

Just to be sure this is clear, "media=print" is something I invented for 
this discussion.  If "media=print" were a valid parameter for text/html, 
then yes, as I understand it, that would be legal in Atom -- I can't see 
any reason why it wouldn't or shouldn't.

---

From: "Ross Singer" <[email-masked]>
Date: Fri, 19 Sep 2008 12:48:56 -0400

On Fri, Sep 19, 2008 at 11:35 AM, Antone Roundy <[email-masked]> wrote:
> then yes, as I understand it, that would be legal in Atom -- I can't see any
> reason why it wouldn't or shouldn't.
>
Well, that's not quite what I was asking (although raises another
question) -- I meant text/html and text/html;media=print are unique
content-types in the eyes of an Atom validator (ignoring validity with
regards to RFC2854 for the sake of argument)  and can therefore both
be used as link rel="alternate" types in the *same* Atom context (i.e.
feed or entry).  Is this true?

But the other question would be, who is that determines the validity
of parameters for mime-types?  Reading the RFCs this seems a little
ambiguous.  There are required parameters and optional parameters, but
I don't see anything where providing a parameter that isn't set in the
RFC is illegal or somehow invalid.  I will be the first to admit that
I have not read RFCs 1521, 1522, 3023 and all their kin from cover to
cover, but would like to hear from somebody that feels they can
confidently answer this.

RFC3023 sort of brings this up in the appendices (A.5-A.10), but I am
having trouble understanding the implications of using custom
parameters to disambiguate representations in an ambiguous mime-type
(of course realizing that agents that are unaware of any convention
being used wouldn't be able to use it).

And the reason why I bring this up, specifically, is because I had
planned on using a method similar to this to allow alternate links to
atom feeds containing different metadata formats *of the same
resources* within entry:content.

Corrections and guidance welcome.
-Ross.