Re: Atom Entry Documents
*If* the document proceeds to Proposed Standard, the new RFC would update RFC4287 either by adding a new type param or by deprecating the use of application/atom+xml for atom entry documents in favor of a new media type. No other part of RFC4287 would be affected. Ideally, I would much rather this be a WG draft. I pinged Tim about it the other day and he suggested that I go ahead with a I-D for now and that we can explore whether or not to move forward with it as a WG draft later. - James Mark Nottingham wrote: What would the relationship of that document be to RFC4287? Cheers, On 2006/12/11, at 7:32 PM, James M Snell wrote: The I-D would be an individual draft, not a WG draft. -- Mark Nottingham http://www.mnot.net/
Re: Atom namespace really not ending with / or # ?
On Tue, 12 Dec 2006 08:18:49 +0100, Jan Algermissen [EMAIL PROTECTED] wrote: is it really true that the Atom namespace is http://www.w3.org/2005/Atom ? Yes. Meaning that it is somewhat difficult to identify Atom elements with URIs: http://www.w3.org/2005/Atomauthor http://www.w3.org/2005/Atomconributor Isn't that only relevant for RDF vocabularies? Was that simply a mistake or a design feature when Atom was standardized? It wasn't really relevant, I'd say. (That it says Atom and not atom was a mistake.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Atom namespace really not ending with / or # ?
http://www.w3.org/2005/Atomauthor http://www.w3.org/2005/Atomconributor On 12/12/06, Anne van Kesteren [EMAIL PROTECTED] wrote: Isn't that only relevant for RDF vocabularies? No, it's relevant for all types of XML work, from XLink to Topic Maps to XHTML. But there's a difference between http://www.w3.org/2005/Atom used as a namespace declaration and a document pointer, though. For a lot of us data modeling types it would be good to use bits of the Atom spec in controlled vocabularies, for example, and we mix these types of models up all the time. Umm, at least I do. :) Alex -- Ultimately, all things are known because you want to believe you know. - Frank Herbert __ http://shelter.nu/ __
Re: Atom namespace really not ending with / or # ?
Jan Algermissen wrote: Hi, is it really true that the Atom namespace is http://www.w3.org/2005/Atom ? Meaning that it is somewhat difficult to identify Atom elements with URIs: http://www.w3.org/2005/Atomauthor http://www.w3.org/2005/Atomconributor Was that simply a mistake or a design feature when Atom was standardized? Thinks I asked for a trailing '/' at some point; certainly for fnalising APP, I want a trailing '/'. cheers Bill
Re: Atom Entry Documents
Hi Mark, I realize the question is part process and part technical, but here's my wish for the technical portion: I'm hoping that whatever is done can be additive and optional, such that it can enable new capabilities without disrupting existing usage of 4287 (only). This is one of the reasons why I prefer that we use optional type qualifiers (Option A) rather than deprecating one mime type and creating two new ones (Option B). Cheers! -- Kyle On 12/12/06, Mark Nottingham [EMAIL PROTECTED] wrote: What would the relationship of that document be to RFC4287? Cheers, On 2006/12/11, at 7:32 PM, James M Snell wrote: The I-D would be an individual draft, not a WG draft. -- Mark Nottingham http://www.mnot.net/
Re: Atom Entry Documents
On 12/12/06, James M Snell [EMAIL PROTECTED] wrote: *If* the document proceeds to Proposed Standard, the new RFC would update RFC4287 either by adding a new type param or by deprecating the use of application/atom+xml for atom entry documents in favor of a new media type. No other part of RFC4287 would be affected. Ideally, I would much rather this be a WG draft. I pinged Tim about it the other day and he suggested that I go ahead with a I-D for now and that we can explore whether or not to move forward with it as a WG draft later. I'm uncomfortable with this. If there's consensus to do something about identifying entry documents, let's do that. If there isn't, let's not. Mark.
Re: Atom namespace really not ending with / or # ?
Anne van Kesteren wrote: Jan Algermissen [EMAIL PROTECTED] wrote: is it really true that the Atom namespace is http://www.w3.org/2005/Atom ? It wasn't really relevant, I'd say. (That it says Atom and not atom was a mistake.) I'd agree. Sigh. But not a big one, I think -Tim
Re: Atom Entry Documents
Mark Baker wrote: Ok, the recent discussion seems to point towards a consensus towards distinctly flagging Entry Documents in the media type. Erm, isn't it up to the chairs to declare concensus? co-chair-modeI agree that there exists sentiment in favor of there being a way to distinguish between Feed and Entry documents. I think the notion of consensus is only meaningful in the context of actual spec language, so it seems to me that it would be helpful to have some proposed language to look at. So I see no downside in James doing an I-D./co-chair-mode -Tim
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.
