Re: PaceEntryMediatype

2006-12-11 Thread Sylvain Hellegouarch
Bob Wyman wrote: > On 12/10/06, Eric Scheid <[EMAIL PROTECTED]> wrote: >> The only danger [of defining a new media type] is if someone has > implemented >> APP per the moving target which is Draft-[n++] ... they should >> revise their test implementations as the draft updates, and certainly >> upd

Reviving Atom Export

2006-12-11 Thread Alastair Rankine
So I got a bit distracted for a bit. Here's what we were talking about. ### What is it? Atom Export is a proposal for a standard/convention/something for the export of content from a CMS (think blogging engine) in a format that is similar to other Atom standards. The assumption here is that

Re: PaceEntryMediatype

2006-12-11 Thread Bill de hOra
Sylvain Hellegouarch wrote: I still don't understand the meaning of equivalence between an entry document and a single-entry-feed document. You don't need to; it doesn't exist. This is string theory for syndication. cheers Bill

Re: PaceEntryMediatype

2006-12-11 Thread Bill de hOra
Bob Wyman wrote: The impact here is not just limited to APP implementations. If a new media type is defined, it will undoubtedly appear in other contexts as well. Given the current definition of the atom syntax, it is perfectly reasonable for an "aggregator" to treat a single entry as the sem

Re: Atom Entry Documents

2006-12-11 Thread Asbjørn Ulsberg
On Sun, 10 Dec 2006 20:19:53 +0100, James M Snell <[EMAIL PROTECTED]> wrote: Option A) Optional Type Param application/atom+xml; type=entry application/atom+xml; type=feed +1. I believe that a type parameter allows more smoothly for new types to be introduced in the future, plus it

Re: Atom Entry Documents

2006-12-11 Thread Judy Piper
Option A) Optional Type Param >application/atom+xml; type=entry >application/atom+xml; type=feed +1 IMO, new optional type parameters make more sense. Judy- On 12/10/06, James M Snell <[EMAIL PROTECTED]> wrote: Ok, the recent discussion seems to point towards a consensus towards distinct

Re: Atom Entry Documents

2006-12-11 Thread Ernest Prabhakar
On Dec 10, 2006, at 11:19 AM, James M Snell wrote: Option B) New Entry media type application/atom.entry+xml +1 I presume the whole reason we need this is that *existing* parsers are "blindly" assuming that application/atom+xml means a feed document. If that is an invalid assumption

Re: Atom Entry Documents

2006-12-11 Thread Kyle Marvin
On 12/10/06, James M Snell <[EMAIL PROTECTED]> wrote: Ok, the recent discussion seems to point towards a consensus towards distinctly flagging Entry Documents in the media type. The only question is whether or not to use a new media type or an optional type param. I'm going to write up an I-D

RE: Atom Entry Documents

2006-12-11 Thread Martin Duerst
At 10:32 06/12/11, Franklin Tse wrote: > >> Option B) New Entry media type > >> application/atom.entry+xml > >+1 +1 #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]

Re: Atom Entry Documents

2006-12-11 Thread Eric Scheid
On 12/12/06 5:56 AM, "Kyle Marvin" <[EMAIL PROTECTED]> wrote: >> application/atom+xml; type=entry >> application/atom+xml; type=feed > I believe other UA-visible Atom document syntax qualifiers will be > needed/coming downstream. For example. ones describing the expected extension > model(s) of

Re: Atom Entry Documents

2006-12-11 Thread Mark Baker
On 12/10/06, James M Snell <[EMAIL PROTECTED]> 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? AFAICT, the discussion I was involved in failed to achieve it.

Re: Atom Entry Documents

2006-12-11 Thread James M Snell
Mark Baker wrote: > On 12/10/06, James M Snell <[EMAIL PROTECTED]> 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? > The I-D would be an individual d

Re: Atom Entry Documents

2006-12-11 Thread James M Snell
Sure you can. Adding this to mime.types... application/atom+xmlatom application/atom+xml;type=entry entry application/atom+xml;type=feed feed works just fine in apache2. Ask for a static file *.atom, and you get application/ato

Re: Atom Entry Documents

2006-12-11 Thread Kyle Marvin
On 12/11/06, Eric Scheid <[EMAIL PROTECTED]> wrote: On 12/12/06 5:56 AM, "Kyle Marvin" <[EMAIL PROTECTED]> wrote: >> application/atom+xml; type=entry >> application/atom+xml; type=feed > I believe other UA-visible Atom document syntax qualifiers will be > needed/coming downstream. For exampl

Atom namespace really not ending with / or # ?

2006-12-11 Thread Jan Algermissen
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

Re: Atom Entry Documents

2006-12-11 Thread Mark Nottingham
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/