On Sun, Apr 03, 2005 at 03:06:26PM -0400, Joe Gregorio wrote:

> I agree with Sam, +1 to the required <link>. The argument that you
> can't have an HTML representation are weak, since *I* can generate
> one for your feed, whether you like it or not.  Now the generated
> HTML may not be optimal but I hope this shows that barrier to
> generating an HTML 'alternate' is not onerous, and that the link
> should remain a MUST.

I think this highlights why I oppose MUST: what on earth is the
utility of this alternate to the end user? The /only/ thing it seems
to do is to provide a way of moving the view of the feed from the Atom
client (which may be able to take advantage of the intrinsic
structure, plus extension metadata) to an HTML client (probably a web
browser), which probably can't do quite as much with it, and certainly
can't do more in the case where the HTML is auto-generated from the
Atom. Which, to the person sitting at the computer, doesn't strike me
as much use.

And since the spec doesn't touch user agent handling of the
rel='alternate' (rightly), even if that were a desirable thing to do,
it won't work with all feeds, since I am in my rights (for instance)
to <atom:link rel='alternate' type='image/png' .../>, an artistic
interpretation of the feed as if it were a swallow.

The spec doesn't tell us precisely enough what alternate is for it to
make sense as a MUST, in my view. Further, I don't think that it is
practical to try to get a precise enough wording for MUST to become
useful; even if it was, it would probably require placing restrictions
on how the Atom clients use the link, which we don't do at the moment
and in IMHO we should not even consider.

I think the argument that it is trivial to produce an HTML
representation of the data in the Atom feed actually reinforces my
point here - if the user agent actually NEEDS an HTML version of the
data, and a link to one isn't supplied, it can generate one
itself. It'll have to do that even with the current wording, since I
can quite happily satisfy the MUST requirement with a non-HTML
version. (Something which I believe can't be done legally with RSS, or
at least not all the different breeds. Not that that matters.)

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [EMAIL PROTECTED]                               uncertaintydivision.org

Reply via email to