I guess I'm assuming that one would want clients to be able to extend
Atom unilaterally. The choices that I highlighted as problematic
make it harder for clients to reliably add extensions to Atom
documents. (It remains easy for servers to add extensions to Atom
feeds and entries using prescribed mechanisms like adding new
elements in custom namespaces. )
Since clients post Atom entries and other clients retrieve them, it
seemed reasonable to want to extend Atom client-to-client. If I used
"AtomFu" client that was able to annotate my entries automatically
with what music I was listening to (track name, album and artist in
XML elements) while I wrote a blog posting, I thought AtomFu should
just store that as XML markup in the entry. Other users running
"AtomFu" will see that information and nobody else needs to upgrade
-- not servers, not other clients. Eventually if other clients see
this as a useful feature they'll make the additional markup visible.
Servers probably would never need to upgrade to use or touch that
markup.
A model where servers aren't required to keep such information won't,
in practice, allow that kind of extension. If clients can't rely on
their markup getting stored, then clients can't extend Atom
unilaterally using XML markup.
But implementors of client software are innovative, too. You can't
stop them from putting cool information in entries -- they'll just
put it in a place where the server decides it's just natural-language
or some other component that it does allow the client to create
unmodified. So maybe instead of seeing track name, album and artist
in XML elements, we'll see them in square brackets or some other
format in the blog entry "text". This will hurt interoperability to
a certain extent, as there is no standard way of extending the
machine-parsable information within the *text* of an entry.
We won't see this today -- with new protocols, servers typically lead
adoption, implementing the protocol before many clients emerge. But
in the long run, server deployments get old and yet as long as
they're still running, admins avoid changing software or even
upgrading. Yet people who've gotten used to the new functionality
start expecting more from it and seek out clients that do cool new
things and still interoperate with their servers. Bare bones clients
are the first generation of a new technology, and innovative
(whatever the barriers) clients come much later.
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?
thx,
Lisa
On Dec 15, 2006, at 8:13 AM, Tim Bray wrote:
The current WG consensus, way better than "rough", is that this
level of interoperation is useful. That consensus seems to be
supported by implementation experience.
Lisa, perhaps the problem is that I'm reacting to a fairly general
statement of concern. Do you have some specific suggestions as to
how server behavior could be limited or formally described?
