Re: Atom Entry docs

2006-12-12 Thread Mark Baker
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 u

Re: Atom Entry docs

2006-12-12 Thread James M Snell
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 > >

Atom Entry docs

2006-12-12 Thread Tim Bray
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

Re: Atom Entry Documents

2006-12-12 Thread Tim Bray
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? I agree that there exists sentiment in favor of there being a way to distinguish between Feed a

Re: Atom namespace really not ending with / or # ?

2006-12-12 Thread Tim Bray
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

2006-12-12 Thread Mark Baker
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 RFC

Re: Atom Entry Documents

2006-12-12 Thread Kyle Marvin
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

Re: Atom namespace really not ending with / or # ?

2006-12-12 Thread Bill de hOra
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 desig

Re: Atom namespace really not ending with / or # ?

2006-12-12 Thread Alexander Johannesen
> 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 differenc

Re: Atom namespace really not ending with / or # ?

2006-12-12 Thread Anne van Kesteren
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

Re: Atom Entry Documents

2006-12-12 Thread James M Snell
*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 th