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

Reply via email to