> 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. Franklin Tse -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt Sent: Friday, November 24, 2006 12:52 To: atom-syntax Subject: Re: PaceResurrectAutodiscovery 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/
