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
