On 12/15/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote:
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.
I do not see the ability of clients to unilaterally extend the APP using XML as a requirement.
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".
You say that as if it's a bad thing. Personally I like microformats. And besides, just because *your* client stuffs a track name, album and artist into some XML does not automatically make it interoperable; every client can, and will, choose to encode that data differently.
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.
See microformats.
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.
Like I stated previously, this has been discussed ad infinitum on the list and the consensus supports it. -joe -- Joe Gregorio http://bitworking.org
