On Dec 15, 2006, at 5:00 PM, Lisa Dusseault wrote:
I guess I'm assuming that one would want clients to be able to
extend Atom unilaterally.
That doesn't seem to have been a design goal for the WG. To the
extent that the issue never came up in the discussion.
The choices that I highlighted as problematic make it harder for
clients to reliably add extensions to Atom documents.
You're being tactful with "harder". I'd say "impossible".
Here's my take on the WG thinking: The set of software
implementations which could reasonably act as APP servers is
incredibly large and heterogeneous. A lot of them already exist.
The requirement that they reliably round-trip arbitrary XML from
clients is actually pretty onerous, since many (all?) of them will
have internal data-storage models which will look very little like
the Atom XML representation.
We think that APP as specified allows very good interoperability for
basic Web-centric publish/edit operations with low overhead, and low
demands for complexity in the client and sever implementations.
Adding the requirement for client-side extensibility would reduce the
number of server implementations that would be able to advertise
conformance with APP, even though they are perfectly capable of the
highly-useful function possible under APP as of the current draft.
(It remains easy for servers to add extensions to Atom feeds and
entries using prescribed mechanisms like adding new elements in
custom namespaces. )
Right. Phrased another way, the APP is highly extensible; but the
current version requires co-operation from both client and server.
This seems reasonable to me.
It may be that I'm just having trouble accepting that the WG fully
understands this and has still come to consensus that this is a
great way to proceed. Is that the case?
Sort of. Frankly, there seems to have been very little hunger for
unilateral client-side extension, and a very strong aversion from the
server-side people to accepting the round-trip-any-XML requirement.
-Tim
