Re: Author element best practice
Well I share the concern because while developing amplee I ran into issues like that. My conclusion was to apply HTTP error handling where I could and where it made sense and leave the rest to the application developer using amplee. For instance return one of the 4xx error code when I meeting the condition for it (missing Content-Length or Content-Type, etc.) Since I started this thread I thought about it and I realized that an APP implementation could not foresee how it would be used and in which context. Thus it cannot safely make a decision in every use case. What amplee does is to provide callbacks to the developer who can then decide how to proceed. - Sylvain James M Snell wrote: I personally just think it's way too early for us to really be able to say much about it. So far the APP implementations that have actually been deployed seem to work rather consistently in that I can get a single client (e.g. Abdera) to work with each with very little effort and only minor variations (e.g. different auth schemes, some require Content-Length on the post, others don't, some reject invalid entries, others don't, etc). Based on my experience thus far, I really don't think it is going to be much of a problem. - James Asbjørn Ulsberg wrote: [snip] Am I the only one pondering and worrying about what the different server implementations will respond to invalid client requests (as, for example, an invalid Atom document)? How can the client implementors be interoperable and compatible with each other and every server implementation if the specification says absolutely nothing about what to expect when something goes wrong? [snip]
Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]
I'm the chairman of the RSS Advisory Board, which has published our first autodiscovery specification [1]. I'd like to participate in the drafting of Atom's effort in this area with the goal of making it possible for publishers to support autodiscovery in the same manner regardless of syndication format. Our original spec said that it could be used with RSS 1.0, RSS 2.0 and Atom, but the Atom guidance was removed to get out of your way as your spec is being drafted. I will put a couple of proposals on the wiki this morning. Regarding your current draft, a couple of editorial suggestions: 1. Are the most relevant rules part of Sections 3.2 and most relevant differences part of 3.3 necessary? It's helpful information, but it documents behavior that's covered by the HTML and XHTML specs, so it seems redundant and makes your spec longer than it needs to be. 2. The href attribute's section is out of order alphabetically. For easier reference, I'd order sections 4.1 through 4.3 as href, rel and type rather than rel, type, href. 3. Your introduction to autodiscovery doesn't describe the most common and popular implementation of the technique. Your graf: Autodiscovered Atom feeds may be presented to the user in a variety of other ways. In the past, Atom-enabled clients have implemented local proxies that monitor visited web sites and notify the end user of autodiscovered Atom feeds in real time. Such notification is also built directly into some desktop web browsers. My suggested rewrite: Autodiscovered Atom feeds can be presented to the user in a variety of other ways. Current versions of the Microsoft Internet Explorer and Mozilla Firefox browsers notify users of the presence of such a feed by displaying an orange feed icon in the browser's address bar. Clicking the icon initiates the process of subscribing to the feed. 1: http://www.rssboard.org/rss-autodiscovery
PaceMakeAutodiscoveryInformational
http://www.intertwingly.net/wiki/pie/PaceMakeAutodiscoveryInformational #pragma section-numbers off == Abstract == Move Autodiscovery forward as an Informational RFC == Status == Proposed == Rationale == At this point there seems to be very little reason for the autodiscovery draft to be on the Standards Track. An Informational RFC would appear to be the most appropriate way forward. == Proposal == Change the status of the autodiscovery draft to Informational. == Impacts == == Notes == CategoryProposals
Restrict Rel and Type Values For Autodiscovery
http://www.intertwingly.net/wiki/pie/PaceRestrictRelValuesForAutodiscovery http://www.intertwingly.net/wiki/pie/PaceRestrictTypeValuesForAutodiscovery While I definitely understand the rationale behind this, it's unlikely that the spec will actually lead to any change in behavior for the various implementations. Also, if memory serves correctly, media types are inherently case-insensitive. We'd likely be better served to document that as a best practice, the rel and type values should be lower case but that many implementations will typically support upper and mixed case values. - James p.s. I also note that the current HTML5 draft contains an editorial note about needing to say something about the case sensitivity of attribute values.
Re: PaceMakeAutodiscoveryInformational
James M Snell wrote: http://www.intertwingly.net/wiki/pie/PaceMakeAutodiscoveryInformational Move Autodiscovery forward as an Informational RFC But if it were published as an informational RFC, what purpose would it serve? I intend to post a much more substantial review of the current draft shortly, but for now, see my comments on the RSS Autodiscovery spec, some of which will also apply to the Atom Autodiscovery spec. http://www.rssboard.org/news/70/vote-rss-autodiscovery-specification#discuss -- Lachlan Hunt http://lachy.id.au/
Re: PaceMakeAutodiscoveryInformational
On Tue, 28 Nov 2006 17:37:03 +0100, James M Snell [EMAIL PROTECTED] wrote: == Proposal == Change the status of the autodiscovery draft to Informational. +1 -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: PaceMakeAutodiscoveryInformational
Lachlan Hunt wrote: [snip] Move Autodiscovery forward as an Informational RFC But if it were published as an informational RFC, what purpose would it serve? To document best practice as it relates specifically to syndication feeds. For example, HTML5 says nothing about whether the relative order of feed autodiscovery links within a document is significant. The Atom autodiscovery draft, however, defines that the order is significant. I intend to post a much more substantial review of the current draft shortly, but for now, see my comments on the RSS Autodiscovery spec, some of which will also apply to the Atom Autodiscovery spec. Excellent. FWIW, I agree with just about all of your comments. - James
Re: PaceMakeAutodiscoveryInformational
On 28 Nov 2006, at 16:37, James M Snell wrote: == Proposal == Change the status of the autodiscovery draft to Informational. +1 There's really no need for it to be a standard, as it's widely implemented in a common way. - Geoffrey Sneddon
Re: PaceMakeAutodiscoveryInformational
James M Snell wrote: Lachlan Hunt wrote: [snip] Move Autodiscovery forward as an Informational RFC But if it were published as an informational RFC, what purpose would it serve? To document best practice as it relates specifically to syndication feeds. The draft makes several requirements. That's not documenting best practice. For example, HTML5 says nothing about whether the relative order of feed autodiscovery links within a document is significant. The Atom autodiscovery draft, however, defines that the order is significant. Which software does that requirement concern? - Rob
Re: PaceMakeAutodiscoveryInformational
Robert Sayre wrote: [snip] To document best practice as it relates specifically to syndication feeds. The draft makes several requirements. That's not documenting best practice. [snip] If the doc is changed to informative, the normative requirements in the draft would need to be relaxed and/or refactored to describe current and best practice. I didn't write the doc so please don't complain to me about what's in there. If there is something that needs to be changed write up a pace. - James
Re: PaceMakeAutodiscoveryInformational
James M Snell wrote: I didn't write the doc so please don't complain to me about what's in there. If there is something that needs to be changed write up a pace. Uh, no. I don't think you should write it at all, and I resent having to waste my time following this completely redundant effort to make sure it doesn't do damage by making requirements that would break backwards compatibility with previous Firefox versions. The WHAT-WG text is fine. - Rob
Re: PaceMakeAutodiscoveryInformational
I do believe that participation in this discussion is optional, as is choosing whether or not to support any particular IETF draft (informational or otherwise) so there is absolutely no need (or desire) for you to waste your time here. Your opinion that the document is unnecessary has been noted. Thanks for the input. - James Robert Sayre wrote: James M Snell wrote: I didn't write the doc so please don't complain to me about what's in there. If there is something that needs to be changed write up a pace. Uh, no. I don't think you should write it at all, and I resent having to waste my time following this completely redundant effort to make sure it doesn't do damage by making requirements that would break backwards compatibility with previous Firefox versions. The WHAT-WG text is fine. - Rob
Re: PaceResurrectAutodiscovery
On 24 Nov 2006, at 01:44, Henri Sivonen wrote: On Nov 23, 2006, at 22:42, Henry Story wrote: This is very nice, in that it opens up the possibility of placing good RDF descriptions of these links at the http://www.iana.org/ assignments/relation/, How could new link relations be described in RDF to such a degree that the description would actually be useful for software processing but simple enough to actually be implemented? Is it realistic to have UAs whacking IANA server effectively performing a DDoS on it? Just some interesting uses of this beyond your question: - The RDF file would serve as a useful machine readable description of the relation, and so serve as documentation. - This would simply make those terms re-useable in other rdf vocabularies, which could be very useful. Do you have an RDF file that needs the notion of an alternate link? Well just use elements from that vocabulary. But to get to your point: The description on the server would probably not be very advanced. It would probably be very simple, like the Dublin Core vocabulary ( http://dublincore.org/ ). And so you are right this would probably not say much more than that :alternate is a relation. Perhaps one could even specify the Domain and the Range of the relation to be documents. Not much that one could automate. The default relations would rarely change, so User Agents would never query the server directly, and so you would not have a DDoS on them. On the other hand, clients wanting to define new relations (as URLs) could place the definitions of these relations on their server, and say some more interesting things such as http://my.eg.com/rel#entry rdfs:subPropertyOf http://iana.org/ assignments/relation/alternate . The user agent would now know that this new entry relation is also an alternate relation. Perhaps this could save having to place both relations inside of every document. as well as making the link relation very extensible (people who want to try out new link relations, can just use their own, unambiguous url). How are full URIs distinguished from strings that need to be appended to http://www.iana.org/assignments/relation/; to obtain the full URI? Are UAs supposed to look for a colon as with XForms input methods? Where is this specified? This is specified in the atom syntax document. [[ The value of rel MUST be a string that is non-empty and matches either the isegment-nz-nc or the IRI production in [RFC3987]. Note that use of a relative reference other than a simple name is not allowed. If a name is given, implementations MUST consider the link relation type equivalent to the same name registered within the IANA Registry of Link Relations (Section 7), and thus to the IRI that would be obtained by appending the value of the rel attribute to the string http://www.iana.org/assignments/relation/;. The value of rel describes the meaning of the link, but does not impose any behavioral requirements on Atom Processors. ]] http://www.atompub.org/rfc4287.html#rfc.section.4.2.7.2 In practice people seem to want to use one-word link relations even when they are coming up with their own. Yes. My guess is that this is because 1. They probably don't think of the issue of name clashes 2. There is no shorthand way of saying something like iana:alternate 3. There is no behavior associated with the name If the relation pointed to a document that could have some behavioral impact on the browser with the user could adjust by doing something at the url of the relation, then there would be an immediate understanding of the value of using URIs. I would recommend you adopt that too. Perhaps you can even adopt the iana name space. If we could get them to put the appropriate rdf document at that location, people who created/coined new link relations could describe these relations as being superproperties or subroperties of relations the browser already knows, which would allow the browser to partially interpret those. Well, RDF is not viewed that favorably by the WHATWG. Also, the barrier for entry for the IANA registration process is likely too high. (It certainly is for MIME types.) As for using the same namespace, the HTML5 definitions for the link types don't necessarily match the Atom definitions. I believe I have a good explanation for why people may have good reasons to dislike RDF/XML. see: http://blogs.sun.com/bblfish/entry/crystalizing_rdf Recently, a WHATWG-managed registry for HTML5 rel values has been discussed informally. The idea was that conformance checkers could consult an online registry instead of only allowing a fixed list of values or allowing everything. RDF is an overkill for this. Even XMDP isn't the simplest thing that could possibly work. The simplest thing that could possibly work is a GETtable text/plain; charset=utf-8 resource at a well-known URI with one rel
PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)
James M Snell wrote: I do believe that participation in this discussion is optional, as is choosing whether or not to support any particular IETF draft (informational or otherwise) so there is absolutely no need (or desire) for you to waste your time here. 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. == 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
+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.
PaceRecommendFullURIsForAutodiscovery
http://www.intertwingly.net/wiki/pie/PaceRecommendFullURIsForAutodiscovery Definite -1 on this one. Buggy implementations just need to be fixed. Writing specs to bugs is silly at best. - James
Re: feed id's and paged/archive feeds
Mark Nottingham wrote: Sorry, this got lost in my inbox... I think they do, although the draft is silent on it. This is one of those areas where it would have been really nice if the WG had agreed to take on FH as part of the core, rather than extension; there are lots of little ambiguities like this as a result. I doubt that would clear things up. This is a HTTP thing, not an Atom thing. My thinking on this matter is that Atom feeds aren't resources, they're representations. Specifically they're a hack/optimisation to deal model collections/iterators for HTTP. Anyone who really cares should try sending Atom over XMPP or email; it'll be clear enough that entrys matter, but feeds don't. [An RDF modelling execise by the WG would have made it clear that feeds are problematic entities, but we'd probably be going into last call sometime the new year as a result.] cheers Bill
Re: PaceMakeAutodiscoveryInformational
2006/11/28, Robert Sayre: The WHAT-WG text is fine. -1 For various reasons, including: http://www.imc.org/atom-syntax/mail-archive/msg19100.html http://www.imc.org/atom-syntax/mail-archive/msg19107.html -- Thomas Broyer
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: PaceRecommendFullURIsForAutodiscovery
James M Snell wrote: http://www.intertwingly.net/wiki/pie/PaceRecommendFullURIsForAutodiscovery Definite -1 on this one. Buggy implementations just need to be fixed. Writing specs to bugs is silly at best. The link element is specified by HTML4/5. -Rob
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: PaceMakeAutodiscoveryInformational
Lachlan Hunt wrote: http://www.rssboard.org/news/70/vote-rss-autodiscovery-specification#discuss Like the Atom Autodiscovery draft, this spec serves no purpose. Autodiscovery is being defined in the HTML5 spec where it belongs, with both the alternate http://www.whatwg.org/specs/web-apps/current-work/#alternate0 and feed http://www.whatwg.org/specs/web-apps/current-work/#feed0 relationships. Fully agree. -Rob
Re: PaceMakeAutodiscoveryInformational
Ok, so given that I think this is the fifth or sixth note in which you've said exactly the same thing, I think your position has been well established. What would be excellent is if you'd give others the opportunity to weigh in on it before trying so hard to filibuster it. - James Robert Sayre wrote: Lachlan Hunt wrote: http://www.rssboard.org/news/70/vote-rss-autodiscovery-specification#discuss Like the Atom Autodiscovery draft, this spec serves no purpose. Autodiscovery is being defined in the HTML5 spec where it belongs, with both the alternate http://www.whatwg.org/specs/web-apps/current-work/#alternate0 and feed http://www.whatwg.org/specs/web-apps/current-work/#feed0 relationships. Fully agree. -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: PaceMakeAutodiscoveryInformational
James M Snell wrote: Ok, so given that I think this is the fifth or sixth note in which you've said exactly the same thing, I think your position has been well established. What would be excellent is if you'd give others the opportunity to weigh in on it before trying so hard to filibuster it. Huh? I'm not sure what you mean--you send way more messages than I do. I'm merely pointing out facts. I think the following entry from the WHAT-WG blog might be of use here. http://blog.whatwg.org/proposing-features Here are some key things that any proposal should include: * What is the problem you are trying to solve * What is the feature you are suggesting to help solve it? * What is the processing model for that feature, including error handling? This should be very clear, including things such as event timing if the feature involves events, how to create graphs representing the data in the case of semantic proposals, etc * Why do you think browsers would implement this feature * Why do you think authors would use this feature? - Rob
Re: PaceMakeAutodiscoveryInformational
James M Snell wrote: Ok, so given that I think this is the fifth or sixth note in which you've said exactly the same thing, I think your position has been well established. What would be excellent is if you'd give others the opportunity to weigh in on it before trying so hard to filibuster it. This looks like an inappropriate personal attack to me. Surely James has been warned about this in the past? - Rob
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: PaceRecommendFullURIsForAutodiscovery
On 28 Nov 2006, at 21:01, Robert Sayre wrote: James M Snell wrote: http://www.intertwingly.net/wiki/pie/ PaceRecommendFullURIsForAutodiscovery Definite -1 on this one. Buggy implementations just need to be fixed. Writing specs to bugs is silly at best. The link element is specified by HTML4/5. -Rob Neither recommends an absolute URL, as that does. - Geoffrey Sneddon
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: PaceMakeAutodiscoveryInformational
At 4:56 PM -0500 11/28/06, Robert Sayre wrote: James M Snell wrote: Ok, so given that I think this is the fifth or sixth note in which you've said exactly the same thing, I think your position has been well established. What would be excellent is if you'd give others the opportunity to weigh in on it before trying so hard to filibuster it. This looks like an inappropriate personal attack to me. co-chair-hat value='on'It may look like that to you, but it does not look that way to the WG Chairs. Please immediately stop posting messages such as this to the mailing list, It gets in the way of the technical discussion. If you cannot stop yourself from posting such messages, please consider not posting any more messages to the mailing list at all. /co-chair-hat
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: [whatwg] PaceAutoDiscoveryDraftIsPointless
On 11/28/06, James M Snell [EMAIL PROTECTED] wrote: 2. Are multiple alternate links with the same type attribute considered to be equivalent regardless of where those links appear in the document. What do you mean by equivalent ? -- Robert Sayre
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: In San Francisco/Bay Area
It has been suggested that a good meeting location might be Tied House in Mountain View [1]. It has a back room that's like a patio but covered and heated for dinner on either Wednesday 6th Dec Friday 8th Dec Monday 11th Dec Wednesday 13th Dec Any preferences? Henry Story [1] http://www.tiedhouse.com/ On 16 Nov 2006, at 18:23, Henry Story wrote: Hi, I am in the San Francisco/Bay Area region for the coming month. Would anyone in the area be up for a group meeting? Henry Home page: http://bblfish.net/ Sun Blog: http://blogs.sun.com/bblfish/ Foaf name: http://bblfish.net/people/henry/card#me
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
Re: In San Francisco/Bay Area
Any of those would be good for me. Be careful of the deep fried onion rings at Tied House, though. Henry Story wrote: It has been suggested that a good meeting location might be Tied House in Mountain View [1]. It has a back room that's like a patio but covered and heated for dinner on either Wednesday 6th Dec Friday 8th Dec Monday 11th Dec Wednesday 13th Dec Any preferences? Henry Story [1] http://www.tiedhouse.com/ On 16 Nov 2006, at 18:23, Henry Story wrote: Hi, I am in the San Francisco/Bay Area region for the coming month. Would anyone in the area be up for a group meeting? Henry Home page: http://bblfish.net/ Sun Blog: http://blogs.sun.com/bblfish/ Foaf name: http://bblfish.net/people/henry/card#me -- John Panzer System Architect http://abstractioneer.org
Autodiscovery Draft Issues
Hi, This feedback is related to the autodiscovery draft. Before reading on, I suggest anyone writing a specification of any kind actually learn a little about how to write good conformance criteria. http://ln.hixie.ch/?start=1140242962count=1 I do not believe it is at all useful for this spec to continue as either normative or informational. If it were to be published as informational, who would it's target audience be? What benefit would it provide to anyone? What purpose would it serve? James M Snell wrote: To document best practice as it relates specifically to syndication feeds. It's not entirely clear what that actually means. How would it be any different from, or more useful than, existing documentation on the subject that has been around for the past 3 or 4 years. What we do need is a normative specification that clearly defines both document and user agent conformance requirements, and that really has to be in a normative specification. The only issue that then remains is where this should take place and, for reasons documented later in this e-mail, I strongly believe that HTML5 is the correct place for this to be defined. For example, HTML5 says nothing about whether the relative order of feed autodiscovery links within a document is significant. The Atom autodiscovery draft, however, defines that the order is significant. That can be considered a limitation of the HTML5 spec which can be addressed there. In fact, at the time of writing this, you've already raised the issue on the WHATWG list and it looks like its been resolved. Note: The rest of this feedback is written as though this spec were still going to be published as a normative RFC, despite the suggestion that it be published as an informational item only or not at all. That's because I had most of it written before that suggestion and it's useful feedback anyway. Feed autodiscovery should ideally be defined independent of the syndication feed format. It is illogical to have a separate autodiscovery spec for Atom [1] and RSS [2]. As far as autodiscovery is concerned, the only difference between these and any other format is the MIME type. But, if this spec is to continue, it should at least be renamed to Syndication Feed Autodiscovery or similar. *Introduction* The introduction should discuss the use of Atom, RSS and RDF Site Summary because they're all widely used and are relevant to anyone implementing autodiscovery. I suggest it also talk about the generic concept of what a syndication feed is (independent of the syntax) and only refer to Atom, RSS and RDF as examples. *Notational Conventions* This section should be titled Conformance Requirements. It should make a clear distinction between user agent conformance and document conformance, and clearly explain the requirements for each. If there are separate categories of user agents, then they should be defined here. For instance, a conformance checker would have different requirements from a web browser. e.g. A conformance checker must report errors to a user, whereas as a web browser isn't required to do so and may recover gracefully, in the way defined by the specification (where applicable). It should state something like the following to define which sections are normative and non-normative. All examples and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative. *Defintion of an autodiscovery element* This should be moved to a separate definitions section (perhaps within the previous conformance requirements section). It does not belong in the Relationship to HTML and XHTML section. The definitions should also include other terms used throughout the spec, which are then used in the conformance requirements (see the writing specifications article linked above). | An Atom autodiscovery element is a link element, as defined in | section 12.3 of HTML 4 [W3C.REC-html401-19991224]. Assuming this section is normative, that reference should be normative also. Throughout the spec, it should also refer to it as just an autodiscovery element (see above about it not just being for Atom). I do not agree that only link elements should be used for autodiscovery. Since visible meta data is always better than invisible meta data, documents should be allowed to use the a element as well. | As with other types of link elements, an autodiscovery element MAY | appear within the head element of an HTML or XHTML document, Why is that requirement only stated as a *MAY*? It should be a *MUST* requirement and it should be made clear that this is a document conformance requirement only. | but it MUST NOT appear within the body. For document conformance, I agree. But, UA conformance requirements also need to be defined. What must a UA do if it finds a link element in the body? This
Re: WHAT-WG, feed and alternate
Robert Sayre wrote: 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). +1 very much on a new media type. The confusion carried by the current one is alarming now but will become a real issue if APP does take off. - Sylvain
