+1.
(As an extension -- not a core part of the APP -- it might be nice if
clients had a way to query a server to see what elements it supported
for a given type of data, perhaps as part of the workspace. I had a
dream last night that this might be as simple as a link relation with a
pointer to a schema document. In this case schemas might be useful for
more than syntax checking. There's probably some obvious flaw in that
idea, though.)
Kyle Marvin wrote:
On 6/15/06, Tim Bray <[EMAIL PROTECTED]> wrote:
So can we drop this stupid debate already? MarkB's proposed
interpretation of PUT is unsupported by the normative specifications
and is violently incompatible with publishing-system reality.
+1. I did some more thinking last night and came up with one real
world scenario where this behavior (accepting and truncating foreign
elements) would be useful, which is all I personally needed to flip
the bit. I'll provide it below for background, I'm sure it won't
convince those who thinks that dropping info on PUT is to be
considered globally evil, but it was enough for me.
Let's say I have two APP stores, once that contains generic Atom
weblog content with no extensions (think Blogger) and one that holds
Atom content with extensions (think Calendar). Let's say I wanted to
put a "Blog this" button on Calendar which would automatically
syndicate information about a calendar event to my blog. When this
happens, the physical operation involved is to use APP to take the
source entry from Calendar (which has extensions) and POST it to my
Blogger APP collection.
When that happens, we could: a) require the client to strip all
Calendar extension data from the event before posting, b) require
Blogger to accept and store arbitrary extension data, or c) allow
Blogger to accept and store only the base syndication components it
knows how to deal with.
Both a) & b) just make life harder for the client or store developer
and don't create any real value. c) makes it pretty seameless. I
would encourage (but not require) the client to add an <atom:source>
element so there is a traversal path back to the full metadata
(imagine a reverse "Calendar this" link in Blogger), but that seems
good enough to me.
I suspect that other analogous scenarios exist in the aggregation
world, where an aggregator might only aggregate a subset of the
content from the original feed (again possibly with source refs for
full fidelity access).
Cheers!
-- Kyle
