Re: PaceAutoDiscoveryDraftIsPointless
Edward O'Connor wrote: Robert Sayre wrote: Don't move forward with the autodiscovery draft. [...] At this point there seems to be no reason for the autodiscovery draft to exist, since the WHAT-WG has ably covered the subject in Web Applications 1.0. I am worried that there are three simultaneous efforts to spec out feed autodiscovery: WA1, the RSS board's recent spec, and this draft. Ideally this stuff would get specced just once. WHAT WG seems like a neutral ground, syndication-format wise, so perhaps they're best positioned to spec feed autodiscovery in a way that makes everybody happy. +1 to speccing this through the WHAT-WG. I'm sure Ian would be happy to address any concerns brought up by this community. ~fantasai
Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
2006/11/29, James M Snell: The problem I have with the WHAT-WG definition of the alternate and feed relations is the unintended conflict that occurs when the alternate representation of a page happens to be an Atom Entry Document. The HTML5 draft says, 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. It goes on to say, The feed keyword indicates that the referenced document is a syndication feed. If the alternate link type is also specified, then the feed is specifically the feed for the current document The problem with this is that the application/atom+xml media type is also used for Atom Entry Documents: link rel=alternate type=application/atom+xml href=entry.xml / The current WHAT-WG definition is inadequate. Already exposed here: http://www.imc.org/atom-syntax/mail-archive/msg19100.html and there: http://www.imc.org/atom-syntax/mail-archive/msg19107.html ;-) There are three possible solutions: 1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom media type is addressed +1 (see above; see also Mark Baker's mail in this same thread –not yet in the archives) 2. We add a type parameter to the application/atom+xml media type to differentiate feed and entry documents, e.g. application/atom+xml;type=feed, application/atom+xml;type=entry +1 When the media type is used without the type parameter, type=feed is assumed. I'd rather say: if there's no 'type' parameter, assume nothing, it can be a feed or entry; this would make the updated media-type fully backwards compatible with the current one (which shipped a year ago). 3. We define a new media type for Atom Entry Documents, e.g. application/atomentry+xml -1 -- Thomas Broyer
RE: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
I would like to have application/atomentry+xml for entry. As a result, application/atom+xml must be a feed. 2. We add a type parameter to the application/atom+xml media type to differentiate feed and entry documents, e.g. application/atom+xml;type=feed, application/atom+xml;type=entry When the media type is used without the type parameter, type=feed is assumed. This cause is ok, but a bit complicated. We have already had a charset parameter. If using both the type and the charset parameters together, then the Content-Type header will be application/atom+xml; type=feed; charset=utf-8. If type parameter is not declared, then type=feed is assumed because most feeds are serving with application/atom+xml with or without the charset parameter today. Franklin Tse -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Broyer Sent: Wednesday, November 29, 2006 16:04 To: Atom-Syntax Subject: Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless) 2006/11/29, James M Snell: The problem I have with the WHAT-WG definition of the alternate and feed relations is the unintended conflict that occurs when the alternate representation of a page happens to be an Atom Entry Document. The HTML5 draft says, 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. It goes on to say, The feed keyword indicates that the referenced document is a syndication feed. If the alternate link type is also specified, then the feed is specifically the feed for the current document The problem with this is that the application/atom+xml media type is also used for Atom Entry Documents: link rel=alternate type=application/atom+xml href=entry.xml / The current WHAT-WG definition is inadequate. Already exposed here: http://www.imc.org/atom-syntax/mail-archive/msg19100.html and there: http://www.imc.org/atom-syntax/mail-archive/msg19107.html ;-) There are three possible solutions: 1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom media type is addressed +1 (see above; see also Mark Baker's mail in this same thread –not yet in the archives) 2. We add a type parameter to the application/atom+xml media type to differentiate feed and entry documents, e.g. application/atom+xml;type=feed, application/atom+xml;type=entry +1 When the media type is used without the type parameter, type=feed is assumed. I'd rather say: if there's no 'type' parameter, assume nothing, it can be a feed or entry; this would make the updated media-type fully backwards compatible with the current one (which shipped a year ago). 3. We define a new media type for Atom Entry Documents, e.g. application/atomentry+xml -1 -- Thomas Broyer
Re: PaceAutoDiscoveryDraftIsPointless
+0. I have no particular agenda on this other than helping to move it forward if that's what folks want. I will note, however, that the overall response to PaceResurrectAutodiscovery was positive and there seemed (to me at least) to be interest in at least discussing the future of the draft. So please stop trying so hard to kill it before folks get a chance to actually think it over and discuss it. Your opinion counts but it's not the only one that matters. - James Robert Sayre wrote: [snip] == Abstract == Don't move forward with the autodiscovery draft. == Status == Proposed == Rationale == At this point there seems to be no reason for the autodiscovery draft to exist, since the WHAT-WG has ably covered the subject in Web Applications 1.0. http://whatwg.org/specs/web-apps/current-work/#alternate0 Reasons given for the continued existence of the IETF draft have been non-technical doubletalk. == Proposal == Stop work on the autodiscovery draft. == Impacts == Reduces mailing list traffic and standards noise.
Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
2006/11/28, Robert Sayre: Nonsense. You know very well that projects I work on will get bug reports on standards compliance if you change something. So, yes, I do have to waste my time here. Since I maintain autodiscovery code people actually use, you'd think my opinion would count for something. If autodiscovery could be defined as in [1], I'd happy to see Firefox (and IE7) have bug reports on standards compliance: I do not use current autodiscovery implementations because I'm not confident in their (undocumented) behavior (among other things, like integration with external aggregators). I'd like autodiscovery documented somewhere, but not as a documentation of current practices (which I think are Bad Things), rather as clean way to do it. However, if any spec (informational or not) tends to only document what's already done, be sure I'll try to kiil it before it's done. -- Thomas Broyer
Re: PaceAutoDiscoveryDraftIsPointless
Edward O'Connor wrote: I am worried that there are three simultaneous efforts to spec out feed autodiscovery: WA1, the RSS board's recent spec, and this draft. Ideally this stuff would get specced just once. WHAT WG seems like a neutral ground, syndication-format wise, so perhaps they're best positioned to spec feed autodiscovery in a way that makes everybody happy. Not only that, they are actually qualified to spec changes to HTML, which is what this is. -Rob
Re: PaceAutoDiscoveryDraftIsPointless
Robert Sayre wrote: Edward O'Connor wrote: I am worried that there are three simultaneous efforts to spec out feed autodiscovery: WA1, the RSS board's recent spec, and this draft. Ideally this stuff would get specced just once. WHAT WG seems like a neutral ground, syndication-format wise, so perhaps they're best positioned to spec feed autodiscovery in a way that makes everybody happy. Not only that, they are actually qualified to spec changes to HTML, which is what this is. -Rob If autodiscovery is only a browser feature then indeed it has nothing to do here. But is it only meant for browsers? - Sylvain
Re: PaceAutoDiscoveryDraftIsPointless
James M Snell wrote: Heh.. I probably should not have been taking a drink when I read this last sentence :-). You do know that we're talking about the *syndication community* right? Actually, it's an HTML issue, so I don't see why the RSS Board or the Atom list or any incarnation of the syndication community would be an appropriate venue. -Rob
Re: PaceAutoDiscoveryDraftIsPointless
Sylvain Hellegouarch wrote: If autodiscovery is only a browser feature then indeed it has nothing to do here. But is it only meant for browsers? Browsers are surely the primary target, but bots and other HTML UAs make use of it. Both uses are covered by the people working on HTML, in the WHAT-WG and the W3C. -Rob
Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
If the Atom/RSS autodiscovery spec describes how to work with the link element to achieve feed autodiscovery in browsers and other clients, isn't it an application of (X)HTML rather than an attempt to specify (X)HTML? My thinking was that we're accomplishing a task similar to the creators of the Robots Exclusion meta tag [1] -- put X values in element Y to achieve effect Z. 1: http://www.robotstxt.org/wc/exclusion.html#meta
Re: PaceAutoDiscoveryDraftIsPointless
On Nov 28, 2006, at 22:11, Edward O'Connor wrote: WHAT WG seems like a neutral ground, syndication-format wise, so perhaps they're best positioned to spec feed autodiscovery in a way that makes everybody happy. +1 for leaving speccing this to the WHATWG. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: PaceAutoDiscoveryDraftIsPointless
Ted, Please correct me if I get any of this incorrect, but for the sake of the discussion I wanted to summarize the HTML5 [1][2] definitions here: The following three links are equivalent to one another and specify that the linked feed is an alternate representation of the page. link rel=alternate type=application/atom+xml href=... / link rel=alternate feed type=application/atom+xml href=... / link rel=feed alternate type=application/atom+xml href=... / This means, for instance, if the links appear on a blog home page that lists the 10 most recent entries, the feed will likely also be a listing of the 10 most recent entries. However, if the link appears on a page that shows a single entry along with a listing of comments that have been received, the link will likely point to an Atom feed listing that entry and it's various comments. Is that correct? HTML 5 defines the feed relation as pointing to a feed that is not necessarily an alternative representation of the page where it is found. This relation can, for instance, be used on a blog home page to point to a comments feed or category feed. link rel=feed type=application/atom+xml href=... / What I did not see in the HTML5 spec is any indication of whether the order of link relations is significant. I'm assuming that means that it is not. I'm also assuming that means that all alternate feed link relations, with the same type attribute value, appearing anywhere within the document are considered to be equivalent? - James [1] http://whatwg.org/specs/web-apps/current-work/#alternate0 [2] http://whatwg.org/specs/web-apps/current-work/#feed0 Edward O'Connor wrote: Robert Sayre wrote: Don't move forward with the autodiscovery draft. [...] At this point there seems to be no reason for the autodiscovery draft to exist, since the WHAT-WG has ably covered the subject in Web Applications 1.0. I am worried that there are three simultaneous efforts to spec out feed autodiscovery: WA1, the RSS board's recent spec, and this draft. Ideally this stuff would get specced just once. WHAT WG seems like a neutral ground, syndication-format wise, so perhaps they're best positioned to spec feed autodiscovery in a way that makes everybody happy. Ted
Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
Rogers Cadenhead wrote: My thinking was that we're accomplishing a task similar to the creators of the Robots Exclusion meta tag [1] -- put X values in element Y to achieve effect Z. Hmm, have to disagree. The behavior is already well-documented, so this isn't accomplishing much. This effort is similar to rewriting the robots exclusion meta tag document. Is there some aspect of the WHAT-WG document that bothers you? Why not provide feedback there? http://whatwg.org/mailing-list The feedback you received from WHAT-WG members on the RSS Board blog was extremely detailed and accurate. - Rob
Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
--- Robert Sayre [EMAIL PROTECTED] wrote: Is there some aspect of the WHAT-WG document that bothers you? Not yet, aside from the notion that they've got an incredibly ambitious goal -- spec the next HTML/XHTML/DOM -- and I have no idea how to gauge the likelihood they'll achieve it. Or whether they'll respect current autodiscovery functionality in MSIE 7 and Firefox 2.0. Why not provide feedback there? I will if that's where autodiscovery goes. But I'm +1 on PaceMakeAutodiscoveryInformational. Seems like a good idea to tell Atom publishers how to support autodiscovered feeds.
Re: PaceAutoDiscoveryDraftIsPointless
James, Please correct me if I get any of this incorrect, but for the sake of [...] What I did not see in the HTML5 spec is any indication of whether the order of link relations is significant. I'm assuming that means that it is not. I'm also assuming that means that all alternate feed link relations, with the same type attribute value, appearing anywhere within the document are considered to be equivalent? These are good questions, but you and I are equally able (or unable) to answer them. Perhaps they would be better asked to the WHAT WG community on their mailing list? http://whatwg.org/mailing-list Ted -- Edward O'Connor [EMAIL PROTECTED] Ense petit placidam sub libertate quietem.
WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
The problem I have with the WHAT-WG definition of the alternate and feed relations is the unintended conflict that occurs when the alternate representation of a page happens to be an Atom Entry Document. The HTML5 draft says, 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. It goes on to say, The feed keyword indicates that the referenced document is a syndication feed. If the alternate link type is also specified, then the feed is specifically the feed for the current document The problem with this is that the application/atom+xml media type is also used for Atom Entry Documents: link rel=alternate type=application/atom+xml href=entry.xml / The current WHAT-WG definition is inadequate. There are three possible solutions: 1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom media type is addressed 2. We add a type parameter to the application/atom+xml media type to differentiate feed and entry documents, e.g. application/atom+xml;type=feed, application/atom+xml;type=entry When the media type is used without the type parameter, type=feed is assumed. 3. We define a new media type for Atom Entry Documents, e.g. application/atomentry+xml Given that there are significantly fewer instances of Atom Entry Documents that would need to be updated and the fact that the ambiguity in the Atom media type has come up as a problem before, I'd actually lean strongly in favor of options 2 or 3. - James Henri Sivonen wrote: On Nov 28, 2006, at 22:11, Edward O'Connor wrote: WHAT WG seems like a neutral ground, syndication-format wise, so perhaps they're best positioned to spec feed autodiscovery in a way that makes everybody happy. +1 for leaving speccing this to the WHATWG. --Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
On 11/28/06, Rogers Cadenhead [EMAIL PROTECTED] wrote: I have no idea how to gauge the likelihood they'll achieve it. Or whether they'll respect current autodiscovery functionality in MSIE 7 and Firefox 2.0. My experience is that the IETF is essentially unresponsive to backward compatibility concerns, to the extent that they will debate the meaning of the term MUST. It's like existential poetry. In my experience, the WHAT-WG doesn't make any changes that break compatibility unless users are already having problems caused by implementation divergence. To make sure this is true, they research and make decisions based on metrics, rather than ill-defined consensus handwaving and individually-authored drafts with no support from client implementors. I've even seen it claimed that servers are clients too, in the IETF. Why not provide feedback there? I will if that's where autodiscovery goes. It is already there. Seems like a good idea to tell Atom publishers how to support autodiscovered feeds. They already know how, in general. The WHAT-WG is the place to work out edge cases in HTML semantics. Sylvain Hellegouarch wrote: there will be little harm done Actually, the proposal seems so poorly researched and poorly coordinated with WHAT-WG that I don't see how you can make that claim. When Pilgrim wrote the draft, there weren't as many existing implementations, so his approach made more sense at the time. -- Robert Sayre
Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
On 11/28/06, James M Snell [EMAIL PROTECTED] wrote: 3. We define a new media type for Atom Entry Documents, e.g. application/atomentry+xml No one relies on Atom Entry alternates now, so this is the best option. We should tack it onto the APP draft, since that will solve issues with the accept element there. And praise to mnot, who suggested we do this in RFC4287 but was overruled by the WG (including myself). -- Robert Sayre
Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
On Nov 28, 2006, at 3:16 PM, Robert Sayre wrote: They already know how, in general. The WHAT-WG is the place to work out edge cases in HTML semantics. Over the course of history, a remarkable number of different groups have jumped up and down and said *We're* the ones defining HTML!!! Listen to *us*!!!. It's foolish to draw conclusions about any HTML- related spec based either on which group is originating it or what anyone claims the browser engineers are going to do. -Tim
Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
On 11/28/06, Tim Bray [EMAIL PROTECTED] wrote: On Nov 28, 2006, at 3:16 PM, Robert Sayre wrote: They already know how, in general. The WHAT-WG is the place to work out edge cases in HTML semantics. Over the course of history, a remarkable number of different groups have jumped up and down and said *We're* the ones defining HTML!!! Listen to *us*!!!. Yes, and *all* have them have done a poor job, except for the WHAT-WG. I am not a frequent participant there, but I have noticed a large leap in quality. For example, Firefox 2 is already shipping section 5.3.5 of HTML5, DOM Storage. http://www.whatwg.org/specs/web-apps/current-work/#scs-client-side I am supposed to be implementing getElementsByClassName today... instead I am posting to this list. *sigh It's foolish to draw conclusions about any HTML- related spec based either on which group is originating it Agree. But the WHAT-WG document and process are much better than the alternatives. or what anyone claims the browser engineers are going to do. Well, I've made the last 5-10 changes to the autodiscovery-related code in one popular browser, so I can go by what I've already done, rather than predicting the future. Here is the bug where I'm going to implement the 'feed' relation, as specified by the WHAT-WG: https://bugzilla.mozilla.org/show_bug.cgi?id=362156 -- Robert Sayre
Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
At 6:16 PM -0500 11/28/06, Robert Sayre wrote: On 11/28/06, Rogers Cadenhead [EMAIL PROTECTED] wrote: I have no idea how to gauge the likelihood they'll achieve it. Or whether they'll respect current autodiscovery functionality in MSIE 7 and Firefox 2.0. My experience is that the IETF is essentially unresponsive to backward compatibility concerns, The IETF has been very good with this on some protocols, and bad on others. Even if a major vendor has deployed something, if it is technically broken or limited, the IETF will generally ignore it. If the protocol is just acceptable, we will spend a huge amount of time trying to decide between good enough and replace it, usually with silly results. to the extent that they will debate the meaning of the term MUST. It's like existential poetry. +1
Re: PaceAutoDiscoveryDraftIsPointless
Hello, Over on the IETF Atom Syntax mailing list we're discussing whether or not to pursue the autodiscovery draft that had previously been put on the table [1] or to simply point to the HTML5 work and be done with it. While reviewing the HTML5 draft and comparing that to the Atom auto-discovery draft, a couple of questions came to mind. 1. Is the order of alternate link rels in a document significant? 2. Are multiple alternate links with the same type attribute considered to be equivalent regardless of where those links appear in the document. Thanks! [1] http://www.ietf.org/internet-drafts/draft-snell-atompub-autodiscovery-00.txt - James Edward O'Connor wrote: James, Please correct me if I get any of this incorrect, but for the sake of [...] What I did not see in the HTML5 spec is any indication of whether the order of link relations is significant. I'm assuming that means that it is not. I'm also assuming that means that all alternate feed link relations, with the same type attribute value, appearing anywhere within the document are considered to be equivalent? These are good questions, but you and I are equally able (or unable) to answer them. Perhaps they would be better asked to the WHAT WG community on their mailing list? http://whatwg.org/mailing-list Ted
Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
* James M Snell [EMAIL PROTECTED] [2006-11-29 00:20]: 3. We define a new media type for Atom Entry Documents, e.g. application/atomentry+xml +1 * Robert Sayre [EMAIL PROTECTED] [2006-11-29 00:40]: We should tack it onto the APP draft, since that will solve issues with the accept element there. And praise to mnot, who suggested we do this in RFC4287 but was overruled by the WG (including myself). +1 (Wow, I +1ed both James and Robert in the same mail. :-) ) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: PaceAutoDiscoveryDraftIsPointless
Sylvain Hellegouarch wrote: I have no will to wait and see whether or not the WHATWG recommendation will eventually be applied. If we have to wait for one or two years to get their final document then I don't see how an informational spec could harm the community while waiting. Don't freak out, but it's going to take *a lot* longer than 1 or 2 years for the WHATWG work to finish. Hixie posted the estimated schedule on www-archive. First Working Draft . . . . 2007 Last Call Working Draft . . 2009 Candidate Recommendation . 2012 Proposed Recommendation . . 2022 http://lists.w3.org/Archives/Public/www-archive/2006Nov/ However, that schedule really only represents the estimated time for a sufficent amount of test cases to be written and for implementations to become fully interoperable. As features get implemented by browsers, you can start using them. e.g. things like canvas or XMLHttpRequest are already widely supported and used, but their specs are not yet finished. It's exactly the same with autodiscovery. Since much of it is already widely supported and the rest of that section is relatively trivial to implement, the official status of the spec won't hold it up at all. But what you can do to speed up the process is to write test cases. Hundreds of them for both HTML and XHTML, especially ones that test for edge cases and non-conforming behaviour. That also helps to reveal holes in the spec, since if you can't test something, it's not specced well enough. +1 to the pace. Why on earth is it called a pace? -- Lachlan Hunt http://lachy.id.au/
Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
On 11/28/06, James M Snell [EMAIL PROTECTED] wrote: There are three possible solutions: 1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom media type is addressed What ambiguity? There's no ambiguity AFAICT. But the WHAT spec does need fixing. Assuming rel=feed because of the value of a (non-authoritative!) media type conflates two independent concepts, and as a result may confuse users who are looking for syndication feeds but instead find themselves confronted with non-traditional (non-feed) Atom documents. If that's fixed, then this should work fine for entries (assuming alternate semantics); link rel=alternate type=application/atom+xml href=foo.atom / There's no need for a new media type. Mark.
Re: [whatwg] Alternate link clarifications [was Re: PaceAutoDiscoveryDraftIsPointless]
Ian Hickson wrote: [snip] Here, while the last three are also valid feeds, it is the first one that should be considered the default when doing auto-discovery. This isn't to say that the feed UA should ignore the other three, or that it should only show them if the user goes out of his way to obtain them -- indeed, the default relationship could be completely ignored. It just means that if it has to automatically pick one, then the first one is the one it should pick. (It might also decide to only pick the one that is both a feed and an alternative representation of the document, instead of picking the default feed.) Hmm... Ok, I can live with that. [snip] Assuming that A includes alternate links to B and C, Can I assume that B is also an alternate of C; and vice versa? Oh, you mean is the 'alternative' link type transitive? I guess so. I've added a paragraph to the spec stating this. [EMAIL PROTECTED] I was trying to think of that word all afternoon. Yes, I was meaning to ask if they were transitive. - James
