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
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
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
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
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
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
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
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
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]
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
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.
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
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
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
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
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/
16 matches
Mail list logo