James M Snell wrote:
Pace to put autodiscovery back in play [1]
Resubmit the Autodiscovery Draft[2] with no changes and submit for
consideration as a Proposed Standard.
I don't think that's a good idea for several reasons, primarily because
feed autodiscovery isn't just for Atom, it's for RSS, RDF and other
syndication formats as well; the quality of the spec is poor; and, as
Henri pointed out, Web Apps 1.0 is already defining it. See below for a
more detailed explanation.
Eric Scheid wrote:
I suggest a relationship value of "feed", to use when pointing to a feed.
I agree.
James M Snell wrote:
My preference would be to maintain the de facto standard that is already
in use by countless sites. I'm just as annoyed as you are about the
ambiguity in the mime type but in this case I think what's currently
deployed trumps what's technically correct.
I agree that compatibility with existing practice is important, but that
doesn't mean the situation can't be improved in a backwards compatible way.
Thomas Broyer wrote:
Henri Sivonen wrote:
The latest WA 1.0 draft covers this as follows:
"If the alternate keyword is used with the type attribute set to the
value application/rss+xml or the value application/atom+xml, then the
user agent must treat the link as it would if it had the feed keyword
specified as well."
http://whatwg.org/specs/web-apps/current-work/#alternate0
This conforts me in thinking that the application/atom+xml media type
should be updated to add a "type" parameter with values "feed" and
"entry".
For the user, why would such a distinction be useful? Also, given what
the WA1 says about rel="alternate feed":
If the alternate link type is also specified, then the feed is
specifically the feed for the current document
Then wouldn't that have effectively the same meaning when used on an
individual article's page?
"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.
No, the MIME type only indicates the format, not the type of relattionship.
http://ietfreport.isoc.org/idref/draft-ietf-atompub-autodiscovery/
The sections Syntax rules inherited from HTML and Syntax rules inherited
from XHTML are not useful. In the case of XHTML, the syntax is defined
by XML. In the case of HTML, the syntax is defined in HTML4 (though
it's being redefined in HTML5). It is not necessary for this spec to
provide a summary of the syntax rules, although it may do so
informatively, it should instead normatively refer to the HTML 4.01,
XHTML 1.0, XML 1.0 and/or (X)HTML5 specs.
The value of the rel attributes are being defined in Web Applications
1.0, as Henri pointed out already. The spec should not mandate the use
of "alternate" for syndication feeds, but rather define "feed" and
specify the conditions under which "alternate" implies "feed" (for
backwards compatibility). That is what WA1 does.
When rel="feed" is used, the type attribute should not be required, and
it most certainly must not specify specific MIME type to use. There are
various syndication formats in use, including Atom, RSS and RDF.
Although, for compatibility when alternate is used, UAs need to treat
application/atom+xml and application/rss+xml specially to imply feed,
the latter may use application/rdf+xml and all three of those may also
use application/xml and (although not recommended) text/xml.
The spec should not require that autodiscovery only work for <link>
elements. The rel and type attributes may also be used on <a> elements
and, although not all existing UAs currently support that, the spec
should define that either <link> or <a> may be used.
From the spec:
| Each autodiscovery element SHOULD point to a different Atom feed.
How should UAs handle cases where 2 links point to the same location?
Should both be presented to the user separately? Should one take
precedence of the other? Which one: the first one? What if one is a
<link> and the other is an <a> in the document? It's common for pages
to include both like that, given that currently only <link> works for
autodiscovery and <a> is useful for UAs that don't support autodiscovery.
The sections rel attribute variations, type attribute variations and
link element variations read like a bunch of test cases. It's good to
provide examples, but these sections have no normative requirements and
it's unnecessary to provide examples for virtually every possible
variation. The examples should ideally be moved up to the sections that
state the normative requirements about the syntax, not be separate
sections on their own.
The references to HTMl4 and XHTML1 should be normative references, not
informative, because those specs define the syntax and semantics of the
elements being used. In other words, it's a requirement that, any UA
implementing this spec, also implements the relevant sections of those
specs.
However, since the Web Applications draft already covers all of these
issues fairly well, I believe it is unnecessary for this draft to be
resurrected. Instead, a few of the good ideas from this draft should be
integrated into the WA1 spec.
--
Lachlan Hunt
http://lachy.id.au/
