Re: atom:content's src and server-driven content negotiation
On 18 Jan 2006, at 12:05 pm, Andreas Sewe wrote: Note, however, that a type attribute on the content element cannot be used since /img is a negotiated resource -- this violates the SHOULD in 4.1.3.2.: 'If the src attribute is present, the type attribute SHOULD be provided [...].' Note the next sentence: The value is advisory So it doesn't have to exactly describe the resource at the other end of the URL. The point is to give the consuming application a useful hint as to what kind of data is there. Which of the above entries is preferable? The correct thing to do is to pick the one provided by default by the server when no content negotiation occurs. eg: content type=image/png href=http://www.example.com/img; / Graham
Re: atom:content's src and server-driven content negotiation
Thursday, January 19, 2006, 11:17:38 AM, Graham Parks wrote: The correct thing to do is to pick the one provided by default by the server when no content negotiation occurs. eg: content type=image/png href=http://www.example.com/img; / Possibly, but that solution isn't perfect. There is a tradeoff between supplying an inaccurate type, and supplying no type at all. This TAG finding [1] discusses the issue quite thoroughly. [1] http://www.w3.org/2001/tag/doc/mime-respect-20040225 The risk in providing an inaccurate mime-type in the content or link elements, is that a user-agent such as a mobile device, might not attempt to fetch the content at all if they don't support the advisory MIME type, even though if they had requested the type, and conneg had taken place, they could have been served a different type that they could have handled. -- Dave
Re: atom:content's src and server-driven content negotiation
On 19 Jan 2006, at 11:53 am, David Powell wrote: Possibly, but that solution isn't perfect. There is a tradeoff between supplying an inaccurate type, and supplying no type at all. This TAG finding [1] discusses the issue quite thoroughly. [1] http://www.w3.org/2001/tag/doc/mime-respect-20040225 The risk in providing an inaccurate mime-type in the content or link elements, is that a user-agent such as a mobile device, might not attempt to fetch the content at all if they don't support the advisory MIME type, even though if they had requested the type, and conneg had taken place, they could have been served a different type that they could have handled. If you read the W3C finding carefully, it doesn't actually cover this exact problem. It comes close in scenario 2 in section 2, section 4.1 and section 5, but doesn't quite get there - all only cover when the advisory type is wrong outright, rather than misleading because of conneg. The recommendation at the end of section 4.1 seems appropriate though. If the advisory type attribute is incompatible, the client should query the resource to double check, or at least offer the user the option of double checking and/or loading the resource anyway. Graham
finishing autodiscovery, like now
PaceAnchorSupport and PaceDifferentRelValue don't seem very useful, and they weren't proposed by implementors. The spec is extremely well-written and reflects existing behavior. Can we please un-expire this: http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html and be done? -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: finishing autodiscovery, like now
* Robert Sayre [EMAIL PROTECTED] [2006-01-19 18:25]: PaceAnchorSupport and PaceDifferentRelValue don't seem very useful, and they weren't proposed by implementors. The spec is extremely well-written and reflects existing behavior. They’re trying to do something useful, but in the wrong way. Both seem to stem from a desire to be able to link feeds other than those which are an alternate of the page in question. But we already have a name for doing that: it’s called “linking to something.” Now, it’d be useful to encourage people to add `type` attributes to their `a` links, so tools could find them just by looking at the page without spidering. But `rel` does not add any information. The page is simply linking to another resource. So +1 to encouraging `type`, -1 on fiddling with `rel` at all (let alone going around changing values). In fact, semantically, we should be encouraging people to move things out of their `link`s and into `a`s in the page. After all, the infrastructure for doing something useful with feeds when a user clicks on a link in the page already exists: MIME types and and `atom:[EMAIL PROTECTED]'self']`. This infrastructure is not well supported; true. But new autodiscovery syntax is not going to become well supported any quicker. Can we please un-expire this: http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html and be done? +1 Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: finishing autodiscovery, like now
On 20/1/06 5:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: But we already have a name for doing that: it¹s called ³linking to something.² Now, it¹d be useful to encourage people to add `type` attributes to their `a` links, so tools could find them just by looking at the page without spidering. But `rel` does not add any information. Here is a link to a resource: link type=application/atom+xml href=... / Please explain how a tool can decide whether that is a link to a atom:feed document, or is a link to an atom:entry document? In fact, semantically, we should be encouraging people to move things out of their `link`s and into `a`s in the page. Sounds like PaceAnchorSupport. How do you propose we do this encouragement, if not by codifying it into a spec? On 20/1/06 4:05 AM, Robert Sayre [EMAIL PROTECTED] wrote: The spec is extremely well-written and reflects existing behavior. The existing behaviour is based on the various incarnations of RSS where the only document type involved are feeds. RFC 4287 introduces a new document type, the Atom Entry Document, which autodiscovery-01 fails to take into consideration. That doesn't meet my definition of well-written. e.
Re: finishing autodiscovery, like now
Quoting Eric Scheid [EMAIL PROTECTED]: On 20/1/06 5:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: But we already have a name for doing that: it¹s called ³linking to something.² Now, it¹d be useful to encourage people to add `type` attributes to their `a` links, so tools could find them just by looking at the page without spidering. But `rel` does not add any information. Here is a link to a resource: link type=application/atom+xml href=... / Please explain how a tool can decide whether that is a link to a atom:feed document, or is a link to an atom:entry document? Why is that relevant? -- Anne van Kesteren http://annevankesteren.nl/
Re: finishing autodiscovery, like now
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote: The existing behaviour is based on the various incarnations of RSS where the only document type involved are feeds. RFC 4287 introduces a new document type, the Atom Entry Document, which autodiscovery-01 fails to take into consideration. That doesn't meet my definition of well-written. Well, if anyone actually did that, it might be a problem. But, then again, it might not be. You've had years to propose your definition of well-written. I think the current draft reflects what implementations do pretty well. We haven't been able to come to consensus on additional features, so I suggest we're done. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: finishing autodiscovery, like now
Eric Scheid wrote: On 20/1/06 5:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: But we already have a name for doing that: it¹s called ³linking to something.² Now, it¹d be useful to encourage people to add `type` attributes to their `a` links, so tools could find them just by looking at the page without spidering. But `rel` does not add any information. Here is a link to a resource: link type=application/atom+xml href=... / Please explain how a tool can decide whether that is a link to a atom:feed document, or is a link to an atom:entry document? This is a general limitation of the media type definition, not with the autodiscovery draft. We have the same problem differentiating atom:link type=application/atom+xml href=... /. This isn't a problem that the autodiscovery draft needs to solve. If it's a problem, solve it in the Atom format spec where the media type is defined. On 20/1/06 4:05 AM, Robert Sayre [EMAIL PROTECTED] wrote: The spec is extremely well-written and reflects existing behavior. The existing behaviour is based on the various incarnations of RSS where the only document type involved are feeds. RFC 4287 introduces a new document type, the Atom Entry Document, which autodiscovery-01 fails to take into consideration. That doesn't meet my definition of well-written. I really don't believe this is going to be much of a problem in practice. - James
Re: finishing autodiscovery, like now
Hi Eric, * Eric Scheid [EMAIL PROTECTED] [2006-01-19 21:10]: Here is a link to a resource: link type=application/atom+xml href=... / Please explain how a tool can decide whether that is a link to a atom:feed document, or is a link to an atom:entry document? this is an excellent point. How does either Pace address it? In fact, semantically, we should be encouraging people to move things out of their `link`s and into `a`s in the page. Sounds like PaceAnchorSupport. How do you propose we do this encouragement, if not by codifying it into a spec? PaceAnchorSupport merely promotes `a` to parity with `link`, for which the I-D says a `rel` attribute consisting of at least `alternate` is required. But I don’t see how “this is a feed I want to link to” implies a different relationship with the linking page than “this is some resource I want to link to.” The mere fact that the linked resource is a feed (or entry document) does not constitute a relationship with the linking page in and of itself; and that makes `rel` the wrong place to shoehorn this information into. So no, encouraging people to add advisory `type` information to their links is not equivalent to PaceAnchorSupport. In any case, the important part is that when someone clicks the link in a browser, the right things happen. For that, the `type` is not even necessary, so long as the feed is served with the correct MIME type and contains a self-link. The type makes some harvesting easier, but ultimately, it’s not *necessary*. We’re trying to shoehorn this functionality in with autodiscovery right now because as of yet, the right things do not happen, even though they *could*, whereas something closer to the right things does happen when autodiscovery links are added willy-nilly. The existing behaviour is based on the various incarnations of RSS where the only document type involved are feeds. RFC 4287 introduces a new document type, the Atom Entry Document, which autodiscovery-01 fails to take into consideration. That doesn't meet my definition of well-written. I don’t know how that is relevant. I am trying to think of a scenario where I’d want to autodiscover an entry document (as opposed to simply linking to it) and the inability to distinguish between feed and entry documents is causing a problem, but I can’t come up with anything. Can you provide an example? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: finishing autodiscovery, like now
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote: The existing behaviour is based on the various incarnations of RSS where the only document type involved are feeds. RFC 4287 introduces a new document type, the Atom Entry Document, which autodiscovery-01 fails to take into consideration. That doesn't meet my definition of well-written. The purpose of Atom autodiscovery is for clients who know the URI of a web page to find the location of that page's associated Atom feed. Not an entry but a feed. The autodiscovery is unambiguous on what such a link points to. Now to match RFC 4287 that 'feed' ought to be 'Feed', but that is a rather minor change. -joe -- Joe Gregoriohttp://bitworking.org
Re: finishing autodiscovery, like now
On 1/19/06, A. Pagaltzis [EMAIL PROTECTED] wrote: The existing behaviour is based on the various incarnations of RSS where the only document type involved are feeds. RFC 4287 introduces a new document type, the Atom Entry Document, which autodiscovery-01 fails to take into consideration. That doesn't meet my definition of well-written. I don't know how that is relevant. I am trying to think of a scenario where I'd want to autodiscover an entry document (as opposed to simply linking to it) and the inability to distinguish between feed and entry documents is causing a problem, but I can't come up with anything. Can you provide an example? I have a weblog post. I would like aggregators to discover both the feed for comments (rel=alternate feed) and the feed for my weblog (rel=feed), but I would like search engines and hypothetical Atom-aware browsers and Piggybank-style history miners to discover the Atom Entry document, where they can find just the entry for one-time fetching with no question about what they are getting (rel=alternate). Of course, if we spec only things which include feed in the rel value as being appropriate for aggregators, and all others as not, we still would need to wait three or four years for existing use of alternate alone to die down before any aggregator developer would consider following along and ignoring non-feeds. Phil Ringnalda
Re: finishing autodiscovery, like now
On 1/19/06, Phil Ringnalda [EMAIL PROTECTED] wrote: Of course, if we spec only things which include feed in the rel value as being appropriate for aggregators, and all others as not, we still would need to wait three or four years for existing use of alternate alone to die down before any aggregator developer would consider following along and ignoring non-feeds. First person to need the feature has to spec alternate entry instead of making everyone change to alternate feed. Not it! -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: finishing autodiscovery, like now
Why wouldn't this work? rel=alternate feed rel=alternate entry rel=alternate replies (see [1]) [1]http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-03.txt Phil Ringnalda wrote: On 1/19/06, A. Pagaltzis [EMAIL PROTECTED] wrote: The existing behaviour is based on the various incarnations of RSS where the only document type involved are feeds. RFC 4287 introduces a new document type, the Atom Entry Document, which autodiscovery-01 fails to take into consideration. That doesn't meet my definition of well-written. I don't know how that is relevant. I am trying to think of a scenario where I'd want to autodiscover an entry document (as opposed to simply linking to it) and the inability to distinguish between feed and entry documents is causing a problem, but I can't come up with anything. Can you provide an example? I have a weblog post. I would like aggregators to discover both the feed for comments (rel=alternate feed) and the feed for my weblog (rel=feed), but I would like search engines and hypothetical Atom-aware browsers and Piggybank-style history miners to discover the Atom Entry document, where they can find just the entry for one-time fetching with no question about what they are getting (rel=alternate). Of course, if we spec only things which include feed in the rel value as being appropriate for aggregators, and all others as not, we still would need to wait three or four years for existing use of alternate alone to die down before any aggregator developer would consider following along and ignoring non-feeds. Phil Ringnalda
Re: finishing autodiscovery, like now
On 20/1/06 7:52 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: Here is a link to a resource: link type=application/atom+xml href=... / Please explain how a tool can decide whether that is a link to a atom:feed document, or is a link to an atom:entry document? this is an excellent point. How does either Pace address it? PaceDifferentRelValue addresses this. It suggests using feed as an @rel value to indicate the referenced resource is a feed (ie. is not an entry doc) which can be subscribed to. It doesn't rule out continuing to use alternate for those cases where the feed is actually an alternate to the current document. I am trying to think of a scenario where I¹d want to autodiscover an entry document (as opposed to simply linking to it) and the inability to distinguish between feed and entry documents is causing a problem, but I can¹t come up with anything. Can you provide an example? I'm not talking about autodiscovery of entry documents. I'm talking about autodiscovery of feeds, which (and this is the point) is *different* from autodiscovery of resources with the mime type of application/atom+xml. Apart from Atom Entry Documents, there are also application/ref+xml documents ... and not all of those are RSS 1.0 feeds. Using feed solves the problem for both cases (atom entry and rdf+xml), and potentially any similar problems (eg newsml+xml?). e.
Re: finishing autodiscovery, like now
On 20/1/06 7:57 AM, James M Snell [EMAIL PROTECTED] wrote: Here is a link to a resource: link type=application/atom+xml href=... / Please explain how a tool can decide whether that is a link to a atom:feed document, or is a link to an atom:entry document? This is a general limitation of the media type definition, not with the autodiscovery draft. We have the same problem differentiating atom:link type=application/atom+xml href=... /. This isn't a problem that the autodiscovery draft needs to solve. If it's a problem, solve it in the Atom format spec where the media type is defined. Too late. It would have been nice to have application/atomentry+xml Also, fixing it in the atom format spec doesn't fix the exact same problem autodiscovery has with application/rdf+xml. e.
Re: finishing autodiscovery, like now
On 1/19/06, James M Snell [EMAIL PROTECTED] wrote: Why wouldn't this work? rel=alternate feed rel=alternate entry rel=alternate replies (see [1]) Because rel is a space separated list of link types: http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel I.e. the values are all orthogonal. -joe -- Joe Gregoriohttp://bitworking.org
Re: finishing autodiscovery, like now
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote: PaceDifferentRelValue addresses this. It suggests using feed as an @rel value to indicate the referenced resource is a feed (ie. is not an entry doc) which can be subscribed to. The spec already does this without a new rel value. It doesn't rule out continuing to use alternate for those cases where the feed is actually an alternate to the current document. I am lie-down-in-the-road opposed to PaceDifferentRelValue. Interesting idea. I suggest someone write a DifferentSpec. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: finishing autodiscovery, like now
* Phil Ringnalda [EMAIL PROTECTED] [2006-01-19 22:30]: I am trying to think of a scenario where I'd want to autodiscover an entry document (as opposed to simply linking to it) and the inability to distinguish between feed and entry documents is causing a problem, but I can't come up with anything. Can you provide an example? I have a weblog post. I would like aggregators to discover both the feed for comments (rel=alternate feed) and the feed for my weblog (rel=feed), Is `feed` a relationship of the page with the feed? Is there a reason `a type=application/atom+xml` wouldn’t suffice? but I would like search engines and hypothetical Atom-aware browsers and Piggybank-style history miners to discover the Atom Entry document, where they can find just the entry for one-time fetching with no question about what they are getting (rel=alternate). Okay, so you have two alternates: one with comments, one without. That would be `rel=alternate` in both cases, with `title=Entry` in one of them and `title=Entry with comments` in the other. This is semantically weak, I know. But I don’t see how it can be strengthened. It merely appears to be expressible more precisely because we’re sticking to the weblog use case. What about feeds for a page on a wiki? Say you have one entry document which contains the latest version of the page at the time of retrieval, one feed which lists the history of major edits, one which lists major+minor edits, and let’s say it’s one of those newfangled wikis where you can leave comments on a page separately from the page content, so you have a feed for that as well. How do you tell those apart? Then someone comes around and does this on his site: http://www-128.ibm.com/developerworks/webservices/library/ws-atomwas/ And then someone else does something else. And someone else still uses Atom in yet another clever way. It’s just impossible to specify enough precise semantics to cover everyone’s use cases, and no single app will ever understand all of these disparate semantics. The problem seems simple while you look at it with blog-coloured glasses because that is such a small and well-understood niche of the problem space. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: finishing autodiscovery, like now
* Eric Scheid [EMAIL PROTECTED] [2006-01-19 23:10]: PaceDifferentRelValue addresses this. It suggests using feed as an @rel value to indicate the referenced resource is a feed (ie. is not an entry doc) which can be subscribed to. It doesn't rule out continuing to use alternate for those cases where the feed is actually an alternate to the current document. Quibbling about the assumption that noone would ever want to subscribe to an entry document aside, I guess I can see the point. But `rel` is not the place for that. I don’t think we *do* have a place for it. What you really want is to express that the linked resource adheres to a certain profile. (Hm, what happened to James Snell’s profile extension?) People could be as precise as they care to be, and bots and user agents could support whichever profiles they cared to. You avoid requiring full buy-in from everyone in order to make something useful even though it’s as vague as “feed.” Of course, this requires a mythical hook in HTML to hang the profile information off of… Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: finishing autodiscovery, like now
A. Pagaltzis wrote: (Hm, what happened to James Snell’s profile extension?) In progress. I decided to hold off in favor of a few other higher priority items. Expect a draft on this either later this month or next. - James
Re: finishing autodiscovery, like now
On 20/1/06 8:08 AM, Joe Gregorio [EMAIL PROTECTED] wrote: The purpose of Atom autodiscovery is for clients who know the URI of a web page to find the location of that page's associated Atom feed. Not an entry but a feed. The autodiscovery is unambiguous on what such a link points to. Unambiguous? The autodiscovery spec does not outlaw using [EMAIL PROTECTED]/atom+xml,@rel=alternate] for linking to atom entry documents. It only says that such links may be used to find Atom Feed Documents. This is a subtle nuance. e.
Re: finishing autodiscovery, like now
On 20/1/06 10:10 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: Okay, so you have two alternates: one with comments, one without. That would be `rel=alternate` in both cases, with `title=Entry` in one of them and `title=Entry with comments` in the other. This is semantically weak, I know. @rel contains tokens, @title contains human language content. Would @title=Entrada com comentários also be acceptable? How about @title=Entrata con le osservazioni or @title=Entrée avec des commentaires or @title=Entrada con comentarios or @title=Eintragung mit Anmerkungen? No. This is no basis for auto-whatever. No matter what the @lang might be, the @rel would still contain the same token for each of those possible @title links. It's just English Language Imperialism why it happens to be alternate entry, it could just as easily be specced to be FooBarBaz or 3576.24352.987. e.
Re: finishing autodiscovery, like now
On 20/1/06 10:10 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: And someone else still uses Atom in yet another clever way. Which is precisely why [EMAIL PROTECTED]alternate,@type=atom+xml] is an *ambiguous* way of discovering atom Feeds ... It¹s just impossible to specify enough precise semantics to cover everyone¹s use cases, and no single app will ever understand all of these disparate semantics. Strawman. I'm not suggesting we pre-define all these other cases. I'm suggesting we define this one case (here is a feed document related to this page) in a manner which distinguishes it from other [undefined] cases. The problem seems simple while you look at it with blog-coloured glasses because that is such a small and well-understood niche of the problem space. Be careful what you assume. I'm thinking of using atom entry documents for many non-blog related purposes, and this is what is driving my interest in disambiguating feed autodiscovery. e.
Re: finishing autodiscovery, like now
On 20/1/06 8:52 AM, Joe Gregorio [EMAIL PROTECTED] wrote: Why wouldn't this work? rel=alternate feed rel=alternate entry rel=alternate replies (see [1]) Because rel is a space separated list of link types: http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel I.e. the values are all orthogonal. Yes, but that would mean that it *would* work, not that it *wouldn't*. Being orthogonal means that those three links are equivalent to these six links rel=alternate href=1 rel=alternate href=2 rel=alternate href=3 rel=feed href=1 rel=entry href=2 rel=replies href=3 Which is exactly what was intended. e.
Re: finishing autodiscovery, like now
On 1/19/06, Joe Gregorio [EMAIL PROTECTED] wrote: Because rel is a space separated list of link types: http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel https://mail.google.com/mail/ I.e. the values are all orthogonal. Though at this point in this discussion, someone is always duty-bound to point out that the only use of link that HTML actually specifies, for stylesheets, treats them as not orthogonal (alternate stylesheet is not alternate and a stylesheet, it's an alternate-stylesheet), and further assigns meaning to the presence (though not, exactly, the content) of a title attribute. Phil Ringnalda
Re: finishing autodiscovery, like now
On 20/1/06 8:31 AM, Robert Sayre [EMAIL PROTECTED] wrote: First person to need the feature has to spec alternate entry instead of making everyone change to alternate feed. How is speccing alternate entry helpful? That would *still* be considered an autodiscovery link to a feed, according the current autodiscovery spec. That's the problem right there. The spec should allow for the creation of other specs without land-grabbing the non-specific alternate @rel value. e.
Re: finishing autodiscovery, like now
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote: That would *still* be considered an autodiscovery link to a feed, according the current autodiscovery spec. That's the problem right there. It's not a problem. It works now, and no one is going to run out and change the running code. If someone did do alternate entry, I can see implementations getting patches to ignore those. In fact, you don't even need a spec to help. Just start doing it. If it becomes common, there will be patches. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: finishing autodiscovery, like now
Eric Scheid wrote: Yes, but that would mean that it *would* work, not that it *wouldn't*. Being orthogonal means that those three links are equivalent to these six links rel=alternate href=1 rel=alternate href=2 rel=alternate href=3 rel=feed href=1 rel=entry href=2 rel=replies href=3 Which is exactly what was intended. Yep. Specifying them as separate tokens provides backwards compatibility (with clients that are actually implemented properly) and better semantics. Folks that rely just on the alternate mechanism won't be any worse off than they are currently. Folks that want the clearer and specific semantics would look for feed, entry, replies - James
Re: finishing autodiscovery, like now
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote: On 20/1/06 8:08 AM, Joe Gregorio [EMAIL PROTECTED] wrote: The purpose of Atom autodiscovery is for clients who know the URI of a web page to find the location of that page's associated Atom feed. Not an entry but a feed. The autodiscovery is unambiguous on what such a link points to. Unambiguous? The autodiscovery spec does not outlaw using [EMAIL PROTECTED]/atom+xml,@rel=alternate] for linking to atom entry documents. It only says that such links may be used to find Atom Feed Documents. This is a subtle nuance. That is not a subtle nuance but an incorrect interpretation. By that same logic it does not outlaw using [EMAIL PROTECTED]/atom+xml,@rel=alternate] to point to an RSS feed, or a PNG. The autodiscovery spec would be the only RFC that defines the behaviour of [EMAIL PROTECTED]/atom+xml,@rel=alternate], and the verbage in the autodiscovery spec is unambiguous about that fact that it is talking about feeds and not entries. -joe -- Joe Gregoriohttp://bitworking.org
Re: finishing autodiscovery, like now
On 1/19/06, Phil Ringnalda [EMAIL PROTECTED] wrote: On 1/19/06, Joe Gregorio [EMAIL PROTECTED] wrote: Because rel is a space separated list of link types: http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel https://mail.google.com/mail/ I.e. the values are all orthogonal. Though at this point in this discussion, someone is always duty-bound to point out that the only use of link that HTML actually specifies, for stylesheets, treats them as not orthogonal (alternate stylesheet is not alternate and a stylesheet, it's an alternate-stylesheet), and further assigns meaning to the presence (though not, exactly, the content) of a title attribute. Marvelous. Are you suggesting we promulgate that behaviour in the face of autodiscovery for RSS that already uses alternate? -joe -- Joe Gregoriohttp://bitworking.org
Re: finishing autodiscovery, like now
On 20/1/06 12:32 PM, Joe Gregorio [EMAIL PROTECTED] wrote: On 1/19/06, Phil Ringnalda [EMAIL PROTECTED] wrote: Though at this point in this discussion, someone is always duty-bound to point out that the only use of link that HTML actually specifies, for stylesheets, treats them as not orthogonal (alternate stylesheet is not alternate and a stylesheet, it's an alternate-stylesheet), and further assigns meaning to the presence (though not, exactly, the content) of a title attribute. Marvelous. Yeah, awful. Are you suggesting we promulgate that behaviour in the face of autodiscovery for RSS that already uses alternate? Speaking for myself, quite the opposite. Robert Sayre is the only one so far suggesting that @rel=alternate entry should be treated as excluding the semantic of @rel=alternate. Which is surprising: I would have bet he would consider the alternate stylesheet thing an abomination. I'm suggesting that if we want to link to a resource which is considered to be a feed for the current document we use feed. If we want to link to a resource which is considered to be an alternate representation of the current document we use alternate. If the resource is considered to be both, then the x/html spec allows both relationships to be expressed in the one link as a space separated list. Specifying feed does not rule out using alternate feed for backwards incompatibility purposes, except to those implementations that can't cope with more than one value in @rel, and according to the autodisco 1.0 spec they are broken anyways so I have no compassion for them. e.
Re: finishing autodiscovery, like now
Joe Gregorio wrote on 1/19/2006, 5:29 PM: On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote: On 20/1/06 8:08 AM, Joe Gregorio [EMAIL PROTECTED] wrote: The purpose of Atom autodiscovery is for clients who know the URI of a web page to find the location of that page's associated Atom feed. Not an entry but a feed. The autodiscovery is unambiguous on what such a link points to. Unambiguous? The autodiscovery spec does not outlaw using [EMAIL PROTECTED]/atom+xml,@rel=alternate] for linking to atom entry documents. It only says that such links may be used to find Atom Feed Documents. This is a subtle nuance. That is not a subtle nuance but an incorrect interpretation. By that same logic it does not outlaw using [EMAIL PROTECTED]/atom+xml,@rel=alternate] to point to an RSS feed, or a PNG. The autodiscovery spec would be the only RFC that defines the behaviour of [EMAIL PROTECTED]/atom+xml,@rel=alternate], and the verbage in the autodiscovery spec is unambiguous about that fact that it is talking about feeds and not entries. What autodiscovery links should I do on a web page that displays a single blog entry, like this one? http://journals.aol.com/panzerjohn/abstractioneer/entries/1238 It's not unreasonable to link to the overall feed for the entire blog from this page, but it's a bit unreasonable to say that the feed is an 'alternate' for the current page -- it's a superset of the current page, at best. It's also not unreasonable to want to have a way to find an individual Atom entry associated with this page. This would intuitively seem to be a reasonable 'alternate' since it contains the same information in a different format. -- John Panzer Sr. Technical Manager http://journals.aol.com/panzerjohn/abstractioneer
Re: finishing autodiscovery, like now
On 1/19/06, John Panzer [EMAIL PROTECTED] wrote: What autodiscovery links should I do on a web page that displays a single blog entry, like this one? http://journals.aol.com/panzerjohn/abstractioneer/entries/1238 Actually on my blog each page has a feed associated with it that is a feed of all the comments on that page. Regardless, the current spec is unambiguous, it points to feeds. If we want it to point to something besides a feed it has to be changed. If we were to change something, one way to disambiguate feeds from entries would be to add a parameter to the mime-type: application/atom+xml; doc=entry -joe -- Joe Gregoriohttp://bitworking.org
invention (was: finishing autodiscovery, like now)
On 1/19/06, John Panzer [EMAIL PROTECTED] wrote: It's not unreasonable to link to the overall feed for the entire blog from this page, but it's a bit unreasonable to say that the feed is an 'alternate' for the current page -- it's a superset of the current page, at best. It's also not unreasonable to want to have a way to find an individual Atom entry associated with this page. This would intuitively seem to be a reasonable 'alternate' since it contains the same information in a different format. I agree with you. But I don't want to change the document. There are lots of other strings we could use to describe new capabilities, and the advantages of continually re-using the string alternate are pretty slim... are there any? An alternate link with a feedish media type means associated feed, and all of the running code on the planet agrees with me. We can either innovate in the WG, or finish in a month or so. I know I prefer the latter. HTML link relations don't require a standards group to add new ones, so people who want to do something can publish them, and they can go code it. There are lots of open source browsers. But, I could be in the minority. Which WG members think we should work on exciting new HTML link relations? -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: finishing autodiscovery, like now
On 20/1/06 1:55 PM, Joe Gregorio [EMAIL PROTECTED] wrote: What autodiscovery links should I do on a web page that displays a single blog entry, like this one? http://journals.aol.com/panzerjohn/abstractioneer/entries/1238 Actually on my blog each page has a feed associated with it that is a feed of all the comments on that page. Are the comments on the same html page, or on another page? Some websites do it the latter way. It often depends on the size of the article, especially if the article is split into multiple pages (eg. http://www.xml.com/pub/a/2005/12/07/catching-up-with-the-atom-publishing-pr otocol.html ). In the first use case, it would make sense to have @rel=alternate feed replies (it's an alternate representation of the page, it's a feed of updates of this page, and it's a resource containing replies to this page). In the latter case however @rel=alternate feed replies would be broken. The replies are not on that page, so how is a feed of replies an alternative representation? It would make sense to have @rel=related feed replies though. Regardless, the current spec is unambiguous, it points to feeds. If we want it to point to something besides a feed it has to be changed. No, it does *not* point to feeds, it points to resources of a certain mime type of which a subset are feeds. There's the ambiguity. e.
