[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PaceResurrectAutodiscovery




2006/11/23, Henry Story:
On 23 Nov 2006, at 14:28, Thomas Broyer wrote:

>
>> "The feed keyword indicates that the referenced document is a
>> syndication feed.
>
> "Being a syndication feed" is expressed by the media type, there's no
> need for a 'rel' value.
>
> The only reason for such a 'rel' is to replace the "contents" value in
> the example above:
> <link rel="feed" type="text/html" href="/index.html" />
> <link rel="feed" type="application/atom+xml" href="/feed.atom" />
> in "blog-like" use-cases where an HTML page serves the same purpose as
> a syndication feed, just in an 'alternate' format.

Exactly: you have just made one good point why one should not use
mime types to identify the relation. After all there may be many
different feed representations: html, rss 1.0, rss 2.0, atom,
rdf, ... etc...

My problem is that:
1. there is no need for a "feed alternate" as spec'd by the WhatWG:
  - when you (as an autodiscovery tool) look at a resource, it might
point to a 'feed' within which it is an 'entry' (or 'item'), this
'feed' might be many different formats, if it happens that you know
how to subscribe to one of the proposed formats, you can provide a
"subscribe to feed" ("within which the current 'page' is an 'item'"
implied) button;
  - when you look at resource which is a 'feed' (and this kind of
thing cannot be "autodiscovered"), then you'll have links to other
formats as 'alternate's, if it happens that you know how to subscribe
to on the proposed formats, you can provide a "subscribe to _this_
feed" (or "subscribe to this page") button
The condition to show a "subscribe" button is whether you know how to
deal with the format, the text you'll use on the button depends on the
relation of this "feed resource" wrt the "current page".
2. stating that if rel="alternate" and @type is RSS or Atom (feed or
entry), then treat the same as rel="feed alternate" is a Bad Thing:
the 'alternate' might be a standalone Atom entry, or might be an
"archive feed": in the former case, a type=entry would disambiguate
it; in the latter case, you'll still provide a "subscribe button"
(because you have no mean to detect it is an "archive feed" without
downloading it) but when the user will click it and you'll dereference
the link, you'll pop up a "the feed is marked as being an archive,
which means it won't be updated, are you sure you want to subscribe?"
message box. If the feed has a <link rel="current" /> with a @type you
know how to deal with, you can change the message box to add "however
the feed provides the location of a 'living feed', do you want to
subscribe to this one instead?".

So, what I'm saying is: I'm not willing to use media types to identify
relations (the fact that you can technically subscribe to a thing
depends on the format of that thing, whether you can parse it or not),
I'm willing NOT TO use relations to identify "groups of media types"
(the ones looking like feed: a container with metadata and contained
items with their own metadata).

Last, but not least, "alternate stylesheet" has a special meaning, and
using "alternate feed" in a different way is a bit confusing...

My main problem with autodiscovery is this use case: the following
links on an "entry page" in a blog-like scenario, where comments on
the entry are shown at the bottom of the page:
<link rel="alternate" type="application/atom+xml"
   title="A standalone Atom Entry alternate representation, might
even be updatable using HTTP PUT" />
<link rel="XXX" type="application/atom+xml"
   title="Comments on this entry" />
<link rel="YYY" type="application/atom+xml"
   title="Site-wide feed" />

1. the first one should not be seen as a "feed" link; I'm proposing
adding a type=entry parameter to the application/atom+xml media type
to help disambiguation; I'm also disagreeing here with the rule of the
WhatWG (rel="alternate" + "feed" media type => rel="feed alternate")

2. which values to give to XXX and YYY?
If XXX is 'alternate', then you need a type=feed parameter not to
confuse the two first links.
XXX and YYY should not be the same, the relations are not the same:
XXX is "contained" while YYY is a "container".
I'm proposing XXX=alternate and YYY=feed; along with adding a
type={feed,entry} to the application/atom+xml media type.

There are many other good reasons to not use the "alternate" relation
everywhere. The spec [1] for feed makes the case for a useful
distinction between a feed that can be used to track updates of the
content one is looking at,

You don't need a special format for that, you could just regularly
poll the resource with If-Modified-Since and If-None-Match.
A special format (which would just be an 'alternate', and nothing
more) helps present it in a unified way along different web sites.

and something that is just an alternate representation of the content
one is looking at expressed in application/atom+xml format.

That would be 'feed alternate'? If so, then your other case above does
not fall in the 'feed' case: from the WhatWG, "otherwise, the feed is
just a syndication feed, not necessarily
associated with a particular Web page": how can you describe a
relationship between to things (that's what is doing a link) and at
the same time say that the other end of the link is "not associated
with a particular Web page"?

This would be the case for the front of my blog page.

rel=alternate is enough in this case.

--
Thomas Broyer