Re: Atom Entry docs
Ok, so we've had more than just a few people put up their hands and say what Bob said. This week I'll go ahead write up an initial draft of this using the type param option while we wait for the co-chairs to do their hasty consensus grab :-) - James Tim Bray wrote: [snip] co-chair-modeIn case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say yeah what Bob said your co-chairs would probably do a hasty consensus grab./co-chair-mode [snip]
Re: Atom Entry docs
On Tue, 19 Dec 2006 21:27:07 +0100, James M Snell [EMAIL PROTECTED] wrote: Ok, so we've had more than just a few people put up their hands and say what Bob said. This week I'll go ahead write up an initial draft of this using the type param option while we wait for the co-chairs to do their hasty consensus grab :-) «What James said.» ;) -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry docs
On Sat, 16 Dec 2006 01:31:29 +0100, John Panzer [EMAIL PROTECTED] wrote: Or both. Millions of blog entry pages have both an entry and a set of comments on that entry. Yes, it's stretching the concept of 'alternate' a long, long way. Yes, it's a long stretch. RFC 4685 specifies how to build that relationship; rel=alternate is not the appropriate solution. In any case, the relation type 'feed' would be better suited for the feed reference and 'alternate' would suit the Entry reference if the Entry indeed was an alternate representation of the HTML document. Agreed, in an ideal world. Considering that the 'feed' relationship is being baked in WHATWG, I don't think that ideal world is such a utopia. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry docs
* Bob Wyman [EMAIL PROTECTED] [2006-12-14 05:45]: 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them defined, registered, and ready to use.) 2) Leave RFC4287 unchanged. i.e. do NOT re-define application/atom-xml 3) New specifications MAY require that ;type=entry be used. (Note: Just because ;type=entry is used DOES NOT imply that ;type=feed must also be used) +1 Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Atom Entry docs
Thursday, December 14, 2006, 9:04:00 AM, Henri Sivonen wrote: On Dec 13, 2006, at 17:51, Mark Baker wrote: But given that an alternative exists which shouldn't break those servers, why not use it when there's no apparent downside? The downside is that implementations that (quite reasonably) assume that application/atom+xml == feed are also reasonable when they ignore unknown media type parameters. An example would be an HTML page with rel=alternative links pointing to a feed and an Atom Entry document. This seems quite a reasonable use-case, yet if we don't create a new MIME type, then I'd expect that all current feed reader implementations would incorrectly detect the entry document to be a feed, which would be very confusing for the user if they select the entry document, and their feed reader attempts to subscribe to the entry document. Which would either work, and they would get subscribed to a feed that doesn't update, or they'd get an error. Given the options of a new type or a new parameter, I am +1 on the new type. (Although in general, I don't like the proliferation of application/*+xml types, because apps need to do root sniffing for application/xml anyway.) Another issue with MIME parameters is that the old MIME RFCs are inconsistent about the definition of the term media type, which can mean top-level type, top-level/sub-type, or top-level/sub-type with parameters. When Atom was being developed I asked (several times) whether Atom documents are allowed to contain parameters in places that they specify media types, and I got conflicting answers. My perception is that MIME parameters just don't work very well. Another case for a new type is browser dispatch. Operating systems tend not to use MIME types for deciding which application to use. Whilst a feed reader is a sensible application to open a feed in; an entry document should probably be opened in an editing/publishing application. This is not really possible if we use a MIME parameter to distinguish the two document types. -- Dave
Re: Atom Entry docs
On Fri, 15 Dec 2006 13:43:58 +0100, A. Pagaltzis [EMAIL PROTECTED] wrote: 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them defined, registered, and ready to use.) 2) Leave RFC4287 unchanged. i.e. do NOT re-define application/atom-xml 3) New specifications MAY require that ;type=entry be used. (Note: Just because ;type=entry is used DOES NOT imply that ;type=feed must also be used) +1 Did anyone check how widely deployed the entry documents actually are? And how much support there is for them? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Atom Entry docs
I've always interpreted a kind of inheritance relationship between MIME types. It's never wrong to label an Excel file, an XML document, or an Atom Feed as application/octet-stream, because all of those types ARE octet-streams. It is just not as helpful as it could be. Likewise, it is never wrong to label an Atom Feed, as application/xml. It just isn't being optimally helpful. I think that you have to interpret MIME types this way, otherwise a generic XML processing application which labelled content as application/xml would be standards compliant until the day that the Atom RFC was published when it would become un-compliant overnight without anyone touching the code. I don't think that that is the way that standards are supposed to work. So likewise, I see no harm in inventing application/atomentry+xml. Sure, applications can still use application/atom+xml for entries, they just aren't being as helpful as ones that use the more explicit MIME type. -- Dave
Re: Atom Entry docs
On 12/14/06, Tim Bray [EMAIL PROTECTED] wrote: Bob Wyman wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. co-chair-modeIn case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say yeah what Bob said your co-chairs would probably do a hasty consensus grab./co-chair-mode +1 to what Bob said. -joe -- Joe Gregoriohttp://bitworking.org
Re: Atom Entry docs
On 12/15/06, David Powell [EMAIL PROTECTED] wrote: I've always interpreted a kind of inheritance relationship between MIME types. It's telling that James felt it natural to choose the name type for the parameter. Because it really is naming a new type of document. In programming, whenever I find myself sticking a member named type into some class definition, I usually have to admit that I'm hacking in a new subclass definition and subverting the type system. That's what defining the type parameter is doing. Hugh
Re: Atom Entry docs
On 12/15/06, Hugh Winkler [EMAIL PROTECTED] wrote: It's telling that James felt it natural to choose the name type for the parameter. Because it really is naming a new type of document. What would be better than type? Might root work better? It seems to me that application/atom+xm;type=entry describes an Atom document whose root element is `entry/'. The type of the document is atom but it is a kind or type of atom document that has an entry/ element as it's root. Unfortunately, type is being used to mean two completely different things in this context. Would you be happier if the proposal was for the following? application/atom+xml;root=entry application/atom+xml;root=feed One argument for using root is that it might be a usage that would be useful with other mediatypes which have more than one possible root element. Also, using root as the parameter name would ensure that folk don't get confused into thinking that there is any kind of subtyping going on here -- specifying ;type=root is simply providing meta-data which describes a constrained use of the general atom type -- it is no different from doing something like saying: I won't except any feeds that don't have icon/ elements. or, This feed contains no more than 256 entry elements. If one is being exceptionally formal or overly pedantic, I can see how you might argue that a feed constrained to fewer than 257 entries is somehow a sub-type of sub-class of the more general atom type. But, since every distinct instance of the atom type can be described in similar manners, it would mean that every atom instance is a subtype. In some contexts, this observation might be useful. I don't think, however, that such precision is useful in the realm for which we normally are designing Atom... bob wyman
Re: Atom Entry docs
On 12/15/06, Bob Wyman [EMAIL PROTECTED] wrote: On 12/15/06, Hugh Winkler [EMAIL PROTECTED] wrote: It's telling that James felt it natural to choose the name type for the parameter. Because it really is naming a new type of document. What would be better than type? Might root work better? No, my point was that type is right on the money; it correctly describes what you're doing... defining a new mime type, but overloading the parameter mechanism to do so. It seems to me that application/atom+xm;type=entry describes an Atom document whose root element is `entry/'. The type of the document is atom but it is a kind or type of atom document that has an entry/ element as it's root. Unfortunately, type is being used to mean two completely different things in this context. Would you be happier if the proposal was for the following? application/atom+xml;root=entry application/atom+xml;root=feed No. One argument for using root is that it might be a usage that would be useful with other mediatypes which have more than one possible root element. Also, using root as the parameter name would ensure that folk don't get confused into thinking that there is any kind of subtyping going on here -- specifying ;type=root is simply providing meta-data which describes a constrained use of the general atom type -- it is no different from doing something like saying: I won't except any feeds that don't have icon/ elements. or, This feed contains no more than 256 entry elements. If one is being exceptionally formal or overly pedantic, I can see how you might argue that a feed constrained to fewer than 257 entries is somehow a sub-type of sub-class of the more general atom type. But, since every distinct instance of the atom type can be described in similar manners, it would mean that every atom instance is a subtype. In some contexts, this observation might be useful. I! don't think, however, that such precision is useful in the realm for which we normally are designing Atom... Straw man: I didn't even remotely imply that all uses of mime parameters is the same as subclassing. In this case, yes, as betrayed by the natural choice of language. When James's proposal came up, I happened to have just constructed some server code (not Atom-specific) to dispatch PUT and POST based on the mime type of the request entity. You just do a simple string match on the bit in front of the semicolon, and dispatch based on that. It's very easy to parameterize that mechanism: any plugin can declare it handles application/atom+xml. It's not such a big deal if the handler for application/atom+xml has to further dispatch based on the parameters, but you can see it's duplicative. The reason for the duplication is a little imperfection in the modelling. If the WG decides other considerations outweigh this one, programmers will handle it. No biggie. But lots of mime type dispatch code lives in browsers, and in servers, and most of the mime.types-ish files you see never have a semicolon in them. (James is correct that you can put the parameter in mime.types for Apache, but of course that is a case of dispatching based on file extension, not on mime type). Hugh
Re: Atom Entry docs
On 15 Dec 2006, at 12:47, David Powell wrote: An example would be an HTML page with rel=alternative links pointing to a feed and an Atom Entry document. This seems quite a reasonable use-case, yet if we don't create a new MIME type, then I'd expect that all current feed reader implementations would incorrectly detect the entry document to be a feed, which would be very confusing for the user if they select the entry document, and their feed reader attempts to subscribe to the entry document. Which would either work, and they would get subscribed to a feed that doesn't update, or they'd get an error. This is my real issue with just using a MIME type parameter - feed readers normally just ignore an unknown MIME type parameter, so we'd have the same issue (entry documents showing up with feed documents). Creating a MIME type would get around this issue - I think this is really just a time when we have to step back and look at where we are, and choose what to do in this situation, regardless of what is technically correct. - Geoffrey Sneddon
Re: Atom Entry docs
On Fri, 15 Dec 2006 13:47:05 +0100, David Powell [EMAIL PROTECTED] wrote: An example would be an HTML page with rel=alternative links pointing to a feed and an Atom Entry document. My thought on this is that that's actually broken. If not according to RFC 4287 or anything else, it's most likely wrong semantics involved. Ether the current HTML document is an alternate representation of the Atom Entry, or it is an alternate representation of the Feed. In any case, the relation type 'feed' would be better suited for the feed reference and 'alternate' would suit the Entry reference if the Entry indeed was an alternate representation of the HTML document. Alternate representation of web site front pages are typically Feeds, alternate representations of article pages are typically Entries. There's very few cases where a Feed and an Entry can be alternate representations of the same resource. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry docs
Asbjrn Ulsberg wrote: On Fri, 15 Dec 2006 13:47:05 +0100, David Powell [EMAIL PROTECTED] wrote: An example would be an HTML page with rel="alternative" links pointing to a feed and an Atom Entry document. My thought on this is that that's actually broken. If not according to RFC 4287 or anything else, it's most likely wrong semantics involved. Ether the current HTML document is an alternate representation of the Atom Entry, or it is an alternate representation of the Feed. Or both. Millions of blog entry pages have both an entry and a set of comments on that entry. Yes, it's stretching the concept of 'alternate' a long, long way. In any case, the relation type 'feed' would be better suited for the feed reference and 'alternate' would suit the Entry reference if the Entry indeed was an alternate representation of the HTML document. Agreed, in an ideal world. -- John Panzer System Architect http://abstractioneer.org
Re: Atom Entry docs
2006/12/14, Bob Wyman: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. It was exactly the point behind my proposal for this 'type' parameter. -- Thomas Broyer
Re: Atom Entry docs
On Dec 13, 2006, at 17:51, Mark Baker wrote: But given that an alternative exists which shouldn't break those servers, why not use it when there's no apparent downside? The downside is that implementations that (quite reasonably) assume that application/atom+xml == feed are also reasonable when they ignore unknown media type parameters. Given the options of a new type or a new parameter, I am +1 on the new type. (Although in general, I don't like the proliferation of application/*+xml types, because apps need to do root sniffing for application/xml anyway.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Atom Entry docs
--- Bob Wyman [EMAIL PROTECTED] wrote: 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them defined, registered, and ready to use.) 2) Leave RFC4287 unchanged. i.e. do NOT re-define application/atom-xml 3) New specifications MAY require that ;type=entry be used. (Note: Just because ;type=entry is used DOES NOT imply that ;type=feed must also be used) +1 on this approach. RFC4287 is a powerful argument in Atom's favor. Chip away at that spec and we're going to start hearing from Mr. Safe again.
Re: Atom Entry docs
On 12/14/06, Henri Sivonen [EMAIL PROTECTED] wrote: On Dec 13, 2006, at 17:51, Mark Baker wrote: But given that an alternative exists which shouldn't break those servers, why not use it when there's no apparent downside? The downside is that implementations that (quite reasonably) assume that application/atom+xml == feed are also reasonable when they ignore unknown media type parameters. True, but I think it's quite reasonable to interpret that behaviour as a bug. Given the options of a new type or a new parameter, I am +1 on the new type. (Although in general, I don't like the proliferation of application/*+xml types, because apps need to do root sniffing for application/xml anyway.) Let's not go there 8-) See; http://www.w3.org/2001/tag/doc/mime-respect.html#embedded Mark.
Re: Atom Entry docs
Bob Wyman wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. co-chair-modeIn case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say yeah what Bob said your co-chairs would probably do a hasty consensus grab./co-chair-mode -Tim 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them defined, registered, and ready to use.) 2) Leave RFC4287 unchanged. i.e. do NOT re-define application/atom-xml 3) New specifications MAY require that ;type=entry be used. (Note: Just because ;type=entry is used DOES NOT imply that ;type=feed must also be used) Thus, APP would accept application/atom+xml when looking for a feed but might insist that entries be explicitly identified with a disambiguating type parameter. Thus, no code which currently uses application/atom+xml to designate a feed would be broken. Additionally, any code which is properly built and thus ignores unknown types will not be hurt when it sees application/atom+xml;type=entry since it will ignore the type parameter and dig around inside the data to figure out if it is feed or entry. The only code which will be hurt is some potential code that does not follow the existing RFCs for Atom or mime types. It is, I think, OK to occasionally break code that doesn't follow the specs. Whatever the technical arguments may be, I believe it is important from a political point of view that we do not change the definition of things defined in Atom. I am all for extending Atom, but not for changing Atom. We must not change the exiting specification unless there is some really serious harm being done. If we do, we risk losing the trust of at least some members of the community that we've built these last few years... Folk will remember that one of the advantages that is claimed for RSS is that it has been declared to be eternally free from modification. While I personally believe that that is silly, the proponents of RSS do have a point when they speak of the value of stable specs. If we allow the Atom spec to be *changed* so soon after it was accepted and we don't have a really, really good reason for doing it, we will simply have proven the often made claim that standards groups simply can't be trusted with important specifications. We will be encouraging more of the kind of standards making that resulted in the mess that is RSS... bob wyman PS: Since Kyle points out that GData, a Google product, is potentially impacted by the results of this discussion, I should state that I currently work for Google -- although I am not currently assigned to any product or project that has a direct interest in the definition of Atom, APP, etc... My participation in this discussion, at this time, is driven purely by personal interest.
Re: Atom Entry docs
Bob Wyman wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. co-chair-modeIn case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say yeah what Bob said your co-chairs would probably do a hasty consensus grab./co-chair-mode Personally, I would say that if we find the proper way to notify implementors they can't dismiss the type parameter then I'll +1 that option over the new media type. However we know that implementations won't make the effort to take it into account then what's the point over the current status? - Sylvain
Re: Atom Entry docs
+1 to yeah, what Bob said. We'll still have to manage the transition around clients that don't send type=entry to GData services, but if we can point at an APP spec where this param is required on POST/PUT, it's possible to push through this. -- Kyle On 12/14/06, Tim Bray [EMAIL PROTECTED] wrote: Bob Wyman wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. co-chair-modeIn case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say yeah what Bob said your co-chairs would probably do a hasty consensus grab./co-chair-mode -Tim 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them defined, registered, and ready to use.) 2) Leave RFC4287 unchanged. i.e. do NOT re-define application/atom-xml 3) New specifications MAY require that ;type=entry be used. (Note: Just because ;type=entry is used DOES NOT imply that ;type=feed must also be used) Thus, APP would accept application/atom+xml when looking for a feed but might insist that entries be explicitly identified with a disambiguating type parameter. Thus, no code which currently uses application/atom+xml to designate a feed would be broken. Additionally, any code which is properly built and thus ignores unknown types will not be hurt when it sees application/atom+xml;type=entry since it will ignore the type parameter and dig around inside the data to figure out if it is feed or entry. The only code which will be hurt is some potential code that does not follow the existing RFCs for Atom or mime types. It is, I think, OK to occasionally break code that doesn't follow the specs. Whatever the technical arguments may be, I believe it is important from a political point of view that we do not change the definition of things defined in Atom. I am all for extending Atom, but not for changing Atom. We must not change the exiting specification unless there is some really serious harm being done. If we do, we risk losing the trust of at least some members of the community that we've built these last few years... Folk will remember that one of the advantages that is claimed for RSS is that it has been declared to be eternally free from modification. While I personally believe that that is silly, the proponents of RSS do have a point when they speak of the value of stable specs. If we allow the Atom spec to be *changed* so soon after it was accepted and we don't have a really, really good reason for doing it, we will simply have proven the often made claim that standards groups simply can't be trusted with important specifications. We will be encouraging more of the kind of standards making that resulted in the mess that is RSS... bob wyman PS: Since Kyle points out that GData, a Google product, is potentially impacted by the results of this discussion, I should state that I currently work for Google -- although I am not currently assigned to any product or project that has a direct interest in the definition of Atom, APP, etc... My participation in this discussion, at this time, is driven purely by personal interest.
Re: Atom Entry docs what Bob said
yeah what Bob said I'm not sure it is ideal, but it seems the closest to consensus we're ever going to get. +1 On Dec 14, 2006, at 7:08 AM, Rogers Cadenhead wrote: --- Bob Wyman [EMAIL PROTECTED] wrote: 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them defined, registered, and ready to use.) 2) Leave RFC4287 unchanged. i.e. do NOT re-define application/atom-xml 3) New specifications MAY require that ;type=entry be used. (Note: Just because ;type=entry is used DOES NOT imply that ;type=feed must also be used) +1 on this approach. RFC4287 is a powerful argument in Atom's favor. Chip away at that spec and we're going to start hearing from Mr. Safe again.
Re: Atom Entry docs
I've found the arguments in favor of the type param to be more convincing than those in favor of the new media type... ...so +1 to what Bob said. - James Tim Bray wrote: Bob Wyman wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. co-chair-modeIn case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say yeah what Bob said your co-chairs would probably do a hasty consensus grab./co-chair-mode -Tim 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them defined, registered, and ready to use.) 2) Leave RFC4287 unchanged. i.e. do NOT re-define application/atom-xml 3) New specifications MAY require that ;type=entry be used. (Note: Just because ;type=entry is used DOES NOT imply that ;type=feed must also be used) Thus, APP would accept application/atom+xml when looking for a feed but might insist that entries be explicitly identified with a disambiguating type parameter. Thus, no code which currently uses application/atom+xml to designate a feed would be broken. Additionally, any code which is properly built and thus ignores unknown types will not be hurt when it sees application/atom+xml;type=entry since it will ignore the type parameter and dig around inside the data to figure out if it is feed or entry. The only code which will be hurt is some potential code that does not follow the existing RFCs for Atom or mime types. It is, I think, OK to occasionally break code that doesn't follow the specs. Whatever the technical arguments may be, I believe it is important from a political point of view that we do not change the definition of things defined in Atom. I am all for extending Atom, but not for changing Atom. We must not change the exiting specification unless there is some really serious harm being done. If we do, we risk losing the trust of at least some members of the community that we've built these last few years... Folk will remember that one of the advantages that is claimed for RSS is that it has been declared to be eternally free from modification. While I personally believe that that is silly, the proponents of RSS do have a point when they speak of the value of stable specs. If we allow the Atom spec to be *changed* so soon after it was accepted and we don't have a really, really good reason for doing it, we will simply have proven the often made claim that standards groups simply can't be trusted with important specifications. We will be encouraging more of the kind of standards making that resulted in the mess that is RSS... bob wyman PS: Since Kyle points out that GData, a Google product, is potentially impacted by the results of this discussion, I should state that I currently work for Google -- although I am not currently assigned to any product or project that has a direct interest in the definition of Atom, APP, etc... My participation in this discussion, at this time, is driven purely by personal interest.
Re: Atom Entry docs
2006/12/14, Tim Bray: Bob Wyman wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. co-chair-modeIn case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say yeah what Bob said your co-chairs would probably do a hasty consensus grab./co-chair-mode Just in case: yeah what Bob said ;-) -- Thomas Broyer
Re: Atom Entry docs
Tim Bray wrote: Bob Wyman wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. co-chair-modeIn case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say yeah what Bob said your co-chairs would probably do a hasty consensus grab./co-chair-mode hand up...
Re: Atom Entry docs
Tim Bray wrote: Bob Wyman wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. co-chair-modeIn case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say yeah what Bob said your co-chairs would probably do a hasty consensus grab./co-chair-mode hands up
Re: Atom Entry docs
Tim Bray wrote: Bob Wyman wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. co-chair-modeIn case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say yeah what Bob said your co-chairs would probably do a hasty consensus grab./co-chair-mode +1 to what Bob said - Sam Ruby
Re: Atom Entry docs
On Thu, 14 Dec 2006 18:00:17 +0100, Tim Bray [EMAIL PROTECTED] wrote: Bob Wyman wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. co-chair-modeIn case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say yeah what Bob said your co-chairs would probably do a hasty consensus grab./co-chair-mode *Hands up* «What Bob said» -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry docs
Consider GData apps. Their docs aren't clear (tsk, tsk!) about the use of a media type when inserting entries[1], but if they're doing it properly then their services should be keying off of application/atom+xml, and so will break if that's changed. And? Should a status quo be better on the long term? Other server implementations should have the same issue, of course. So please explain me what a server currently does upon receiving an Atom feed on a POST to a collection that only (app:)accept (atom:)entry(ies)? Returning a 415 error code seems like the wrong option since the media-type is perfectly valid. So what should servers do? Should they pick-up randomly one of the entries part of the feed? How should UA deal with the returned message? So I'm for James' option B) application/atom-entry+xml I'm -1 on that, but +1 on the type parameter. I'm still +1 on the new media-type and +0.5 on the parameter type option. - Sylvain
Re: Atom Entry docs
At 13:14 06/12/13, James M Snell wrote: I think atom.entry and atom-entry are equally ugly; atom.entry would, however, appear to be more consistent with typical mime conventions. The dot is used for prefixes like vnd. (vendor) and so on. In the case of atom entries, atom-entry is more in line with the convention in other types. Regards,Martin. - James Tim Bray wrote: [snip] (James, did you really mean atom.entry with the ugly dot?) -Tim #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
Re: Atom Entry docs
Martin Duerst wrote: James M Snell wrote: I think atom.entry and atom-entry are equally ugly; atom.entry would, however, appear to be more consistent with typical mime conventions. The dot is used for prefixes like vnd. (vendor) and so on. In the case of atom entries, atom-entry is more in line with the convention in other types. Right. Please drop the (dot-separated) prefix, especially since there is not such thing as a hierachy here -- unless you are proposing appliction/atom.feed+xml as well, James. (Which you hopefully won't ;-) And while you are at it, why does application/atom-entry+xml contain a hyphen? Both application/atomsvc+xml and application/atomcat+xml do not. We should maintain some consistency here. Speaking of which: What file extension do you recommend for use with application/atomentry+xml? .atomentry? Just .entry? Something else entirely? Regards, Andreas, who still is +1 on a type parameter, but now +0 on a (consistently named!) new media type
Re: Atom Entry docs
On 12/13/06, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Consider GData apps. Their docs aren't clear (tsk, tsk!) about the use of a media type when inserting entries[1], but if they're doing it properly then their services should be keying off of application/atom+xml, and so will break if that's changed. And? Should a status quo be better on the long term? I was just disagreeing with Tim's assertion that nothing will break. Other server implementations should have the same issue, of course. So please explain me what a server currently does upon receiving an Atom feed on a POST to a collection that only (app:)accept (atom:)entry(ies)? Returning a 415 error code seems like the wrong option since the media-type is perfectly valid. So what should servers do? Should they pick-up randomly one of the entries part of the feed? How should UA deal with the returned message? AIUI, that's undefined, and will remain so no matter what is decided here. I don't understand what that has to do with a new media type breaking existing servers though. Of course, APP isn't finished yet, and so technically we shouldn't be worrying about breaking implementations that jumped the gun. But given that an alternative exists which shouldn't break those servers, why not use it when there's no apparent downside? Mark.
Re: Atom Entry docs
At 4:41 PM +0900 12/13/06, Martin Duerst wrote: At 13:14 06/12/13, James M Snell wrote: I think atom.entry and atom-entry are equally ugly; atom.entry would, however, appear to be more consistent with typical mime conventions. The dot is used for prefixes like vnd. (vendor) and so on. In the case of atom entries, atom-entry is more in line with the convention in other types. +1
Re: Atom Entry docs
Very helpful. Thank you. - James Martin Duerst wrote: At 13:14 06/12/13, James M Snell wrote: I think atom.entry and atom-entry are equally ugly; atom.entry would, however, appear to be more consistent with typical mime conventions. The dot is used for prefixes like vnd. (vendor) and so on. In the case of atom entries, atom-entry is more in line with the convention in other types. Regards,Martin. - James Tim Bray wrote: [snip] (James, did you really mean atom.entry with the ugly dot?) -Tim #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
Re: Atom Entry docs
Other server implementations should have the same issue, of course. So please explain me what a server currently does upon receiving an Atom feed on a POST to a collection that only (app:)accept (atom:)entry(ies)? Returning a 415 error code seems like the wrong option since the media-type is perfectly valid. So what should servers do? Should they pick-up randomly one of the entries part of the feed? How should UA deal with the returned message? AIUI, that's undefined, and will remain so no matter what is decided here. I don't understand what that has to do with a new media type breaking existing servers though. It has everything to do within the APP context in fact. We have only one mime type for two distinct semantics (well you disagree on that statement so I can understand why we disagree with the rest). Having a new media-type (or at least the type parameter) would help APP server implementors. Therefore the way servers would handle requests. Of course, APP isn't finished yet, and so technically we shouldn't be worrying about breaking implementations that jumped the gun. But given that an alternative exists which shouldn't break those servers, why not use it when there's no apparent downside? We still disagree on this alternative you suggest I'm afraid. - Sylvain
Re: Atom Entry docs
Sylvain Hellegouarch wrote: [snip] The GData server implementation requires a Content-Type value of application/atom+xml when POSTing or PUTting an Atom entry to a collection (for all non-media collections). It will respond with a 400 (Bad Request) http error on any other content type. It will also do the same if the request body contains an Atom feed document and not an Atom entry document. Right and I find that abusive of the mime type already. An UA that respects RFC 4287 and sends a feed to a collection that would state it accepts such media-type would not understand why it gets a 400 Bad Request (it's fairly interesting to point actually that because of that umbrella mime type you could not use the proper 415). Which is precisely why acceptentry/accept exists. Existing implementations already have to basically ignore the content-type and sniff the content. Implementations will have to continue to do so with the optional type param because it's optional. - James
Re: Atom Entry docs
James M Snell wrote: Sylvain Hellegouarch wrote: [snip] The GData server implementation requires a Content-Type value of application/atom+xml when POSTing or PUTting an Atom entry to a collection (for all non-media collections). It will respond with a 400 (Bad Request) http error on any other content type. It will also do the same if the request body contains an Atom feed document and not an Atom entry document. Right and I find that abusive of the mime type already. An UA that respects RFC 4287 and sends a feed to a collection that would state it accepts such media-type would not understand why it gets a 400 Bad Request (it's fairly interesting to point actually that because of that umbrella mime type you could not use the proper 415). Which is precisely why acceptentry/accept exists. Existing implementations already have to basically ignore the content-type and sniff the content. Implementations will have to continue to do so with the optional type param because it's optional. True but I've always found the entry awkward. - Sylvain
Re: Atom Entry docs
There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them defined, registered, and ready to use.) 2) Leave RFC4287 unchanged. i.e. do NOT re-define application/atom-xml 3) New specifications MAY require that ;type=entry be used. (Note: Just because ;type=entry is used DOES NOT imply that ;type=feed must also be used) Thus, APP would accept application/atom+xml when looking for a feed but might insist that entries be explicitly identified with a disambiguating type parameter. Thus, no code which currently uses application/atom+xml to designate a feed would be broken. Additionally, any code which is properly built and thus ignores unknown types will not be hurt when it sees application/atom+xml;type=entry since it will ignore the type parameter and dig around inside the data to figure out if it is feed or entry. The only code which will be hurt is some potential code that does not follow the existing RFCs for Atom or mime types. It is, I think, OK to occasionally break code that doesn't follow the specs. Whatever the technical arguments may be, I believe it is important from a political point of view that we do not change the definition of things defined in Atom. I am all for extending Atom, but not for changing Atom. We must not change the exiting specification unless there is some really serious harm being done. If we do, we risk losing the trust of at least some members of the community that we've built these last few years... Folk will remember that one of the advantages that is claimed for RSS is that it has been declared to be eternally free from modification. While I personally believe that that is silly, the proponents of RSS do have a point when they speak of the value of stable specs. If we allow the Atom spec to be *changed* so soon after it was accepted and we don't have a really, really good reason for doing it, we will simply have proven the often made claim that standards groups simply can't be trusted with important specifications. We will be encouraging more of the kind of standards making that resulted in the mess that is RSS... bob wyman PS: Since Kyle points out that GData, a Google product, is potentially impacted by the results of this discussion, I should state that I currently work for Google -- although I am not currently assigned to any product or project that has a direct interest in the definition of Atom, APP, etc... My participation in this discussion, at this time, is driven purely by personal interest.
Re: Atom Entry docs
On 12/13/06, Bob Wyman [EMAIL PROTECTED] wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. That's what I thought the type parameter option was, so sure, +1 on that too 8-) Mark.
Atom Entry docs
I seems obvious to me that Atom Feed and Entry docs are potentially quite different things which can be used for entirely different purposes. The contention that an Entry doc is somehow really the same as a one-entry Feed doc is entirely unconvincing. The Architecture of the Web (http://www.w3.org/TR/webarch) and the TAG finding on Authoritative Metadata (http://www.w3.org/2001/tag/doc/mime-respect.html) make it pretty clear that it's advantageous to use HTTP headers to distinguish between different kinds of representations. So I guess I'm in favor of us writing something down to address this problem. RFC4287 is now pretty widely implemented, so there is a distinct cost to screwing around with the well-known application/atom+xml. On the other hand, my perception is that virtually all software that knows about 4287 knows about feeds, rather than entries. Thus, it seems to me that introducing a parameter so that existing software might see application/atom+xml;type=feed *might* break some software. But introducing a new media-type application/atom-entry+xml which only goes with standalone feed documents is very unlikely to break anything. So I'm for James' option B) application/atom-entry+xml (James, did you really mean atom.entry with the ugly dot?) -Tim
Re: Atom Entry docs
I think atom.entry and atom-entry are equally ugly; atom.entry would, however, appear to be more consistent with typical mime conventions. - James Tim Bray wrote: [snip] (James, did you really mean atom.entry with the ugly dot?) -Tim
Re: Atom Entry docs
Tim, On 12/12/06, Tim Bray [EMAIL PROTECTED] wrote: I seems obvious to me that Atom Feed and Entry docs are potentially quite different things which can be used for entirely different purposes. The contention that an Entry doc is somehow really the same as a one-entry Feed doc is entirely unconvincing. The Architecture of the Web (http://www.w3.org/TR/webarch) and the TAG finding on Authoritative Metadata (http://www.w3.org/2001/tag/doc/mime-respect.html) make it pretty clear that it's advantageous to use HTTP headers to distinguish between different kinds of representations. Ok, well, I've already voiced my disagreement that entirely different purposes necessitates a new media type using HTML as an example. I also disagree that the TAG finding has any relevance here, except insofar as it says that a media type authoritatively determines meaning by virtue of pointing at a spec ... but every option on the table, including doing nothing, does that. But so be it, I'm happy to move on ... So I guess I'm in favor of us writing something down to address this problem. RFC4287 is now pretty widely implemented, so there is a distinct cost to screwing around with the well-known application/atom+xml. On the other hand, my perception is that virtually all software that knows about 4287 knows about feeds, rather than entries. Thus, it seems to me that introducing a parameter so that existing software might see application/atom+xml;type=feed *might* break some software. Maybe, but I'd be surprised. Though not, AFAIK, prescribed behaviour, convention is that unknown extension parameters are ignored. Implementors? But introducing a new media-type application/atom-entry+xml which only goes with standalone feed documents is very unlikely to break anything. I think it would break servers. Consider GData apps. Their docs aren't clear (tsk, tsk!) about the use of a media type when inserting entries[1], but if they're doing it properly then their services should be keying off of application/atom+xml, and so will break if that's changed. Other server implementations should have the same issue, of course. So I'm for James' option B) application/atom-entry+xml I'm -1 on that, but +1 on the type parameter. Cheers, [1] http://code.google.com/apis/gdata/protocol.html#Inserting-a-new-entry Mark.
