[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> Web Apps 1.0 is already defining it
> 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.
Web Applications 1.0 is new markup language based on HTML under development. UAs that support feed autodiscovery are not necessary to support Web Apps 1.0. Relying on the definitions in the specification of Web Apps 1.0 is not appropriate.
The reason of using "alternate" is that, "alternate" was already defined the HTML 4.01 Specificiation and it is widely used by UAs. [ http://www.w3.org/TR/html401/types.html#type-links ]
If we need to define more link type, we may need to do the following as recommended by the specification.
"Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details."
On the other hand, the W3C Widgets 1.0 autodiscovery is also using "alternate". [ http://www.w3.org/TR/widgets/#autodiscovery ]
> 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.
I think that only <link> should be used. All feeds linked by <a> should be ignored during the process of autodiscovery.
From: owner-atom-syntax@xxxxxxxxxxxx [mailto:owner-atom-syntax@xxxxxxxxxxxx] On Behalf Of Lachlan Hunt
Sent: Friday, November 24, 2006 12:52
Subject: Re: PaceResurrectAutodiscovery
James M Snell wrote:
> Pace to put autodiscovery back in play 
> Resubmit the Autodiscovery Draft 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.
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."
> This conforts me in thinking that the application/atom+xml media type
> should be updated to add a "type" parameter with values "feed" and
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.
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
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.