+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
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 wi
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
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 wil
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
I feel like this whole discussion about whether an entry is logically
equivalent to a feed is a little bit of a red herring. To me, the
important justification for forking the Atom content type comes from a
belief that this is useful information that you need *before* you
retrieve/process the ta
On 12/1/06, James M Snell <[EMAIL PROTECTED]> wrote:
You're right that the differentiation in the content-type is of less
importance but without it there's no way for me to unambiguously
indicate that a resource has both an Atom Feed representation and an
Atom Entry representation.
I can see
On 12/1/06, James M Snell <[EMAIL PROTECTED]> wrote:
Kyle Marvin wrote:
> [snip]
> I expect that if you associated a 'rel' value with links that point to
> "application/atom+xml", whether it is expected to be a feed or an entry
> would probably be part
I'm still listening to the debate, but Mark's argument resonates with me.
It seems like 'content-type' is more about the expected syntax of the
resource at the other end of the wire, not it's semantic meaning. I don't
see Atom feeds and entries as syntactically different enough to warrant
unique
On 5/4/06, Tim Bray <[EMAIL PROTECTED]> wrote:
>
> On May 4, 2006, at 3:43 PM, Thomas Broyer wrote:
>
> > Things would have been far easier if either a) atom:link were
> > extensible
>
> This assertion that atom:link is not extensible is simply, flatly,
> completely, wrong. I just went and review
On 4/13/06, John Panzer <[EMAIL PROTECTED]> wrote:
>
> Google Calendar has launched (and there was much rejoicing). It uses
> Atom feeds for public calendar information:
> I'm wondering if these have been documented somewhere -- anyone from
> Google on the list?
Hi John,
The extensions used in
11 matches
Mail list logo
