Joe Gregorio wrote:
>[snip]
> I'm worried about interop. Shortly after APP is released I expect to
> see a plethora of extensions, most using namespaced elements in the
> atom entry. It'll be another 'let a 1000 flowers bloom' period like
> we saw for RSS 2.0.
>
I doubt we'll see the kind of organic extension growth we saw with RSS
2.0. What I expect is that we'll end up with a bunch of vendor-specific
implementations (like Gdata) that implement their own
application-specific extensions. Clients will need to be created or
modified to interact with specific server implementations... (e.g.
you'll have gdata clients, blog clients, photo-publishing clients, etc,
each written to the specific requirements of their targeted server
implementations)
>[snip]
> Scenario 1:
> ======
> Client does a GET, edits the entry, then PUTs it back.
>
> We need to answer the following questions:
>
> SHOULD/MAY/MUST the client preserve atom:id, atom:updated, etc? Each one
> of these needs to be answered one by one.
> SHOULD/MAY/MUST the client preserve foreign markup?
>
Tim or Paul can correct me, but I believe the WG already established
consensus on this particular issue. PacePreserveForeignMarkup was
accepted.
I have no problem at all with a mandate that a server reject PUT entries
with different atom:id values.
I think it needs to be made crystal clear that the server can do
whatever it want with the entry, however.
- James
> Scenario 2:
> ======
> Client does a PUT then a GET on the entry just updated.
>
> We need to answer the following questions:
>
> SHOULD/MAY/MUST the server preserve atom:id, atom:updated, etc? Again
> we need an answer for each element.
> SHOULD/MAY/MUST the server preserve foreign markup, etc?
>
> Of course, the other option is to give up on trying to set client
> and server expectations and provide no guidance on the
> preservation/editability of elements in an entry, but even then
> we need to add text to spec that states we are explicitly providing
> no guidance.
>
> Sorry that answer was long-winded and tedious and in the
> end provided no guidance on a solution, but I want to make
> sure we are on the same page and agree that we have a problem.
>
> Thanks,
> -joe
>
