Re: Extending Entry Collections [Long]

["Thomas Broyer" <t.broyer@xxxxxxxxxxx>]

Joe Gregorio wrote:
> In the current draft we have two types of Collections, Generic
> and Entry. We know that we would like other types of Collections,
> whether they are defined in this spec or another, we know that we want
> them.
>
> The two Collections, Generic and Entry, are the most general types of
> collections we would want. Any other type of collection is just going
> to be a subclass of either 'generic' or 'entries'. That is, a
> collection that just accepted images would just be a subclass of
> 'generic'. A collection of Book or Music entries would just be a
> subclass of 'entries'.
[...]
> That only leaves a method for subclassing Entry Collections. To frame
> the discussion look at the Music, Book, People and Link collections
> that the TypePad API implemented:
>
>   http://www.sixapart.com/pronet/docs/typepad_atom_api#Atom_Entry_Elements
>
> When I wrote the draft that the TypePad implementation is based on,
> this is exactly the type of extensions I was thinking of. It was
> precisely what I wanted to see. At this point I have to admit that I
> feel like the kid that wakes up on Christmas morning and gets exactly
> the present I asked for, except that I didn't see the "Not a flying
> toy" label on the box.
>
> I've been mulling the problem for about a year now, and only recently
> figured out what bothers me so much about the SixApart extensions.
> [This is not to cast aspersions on anybody at SixApart. They extended
> the APP in exactly the way I had intended. And it works. I just think
> that there is a better way.]
>
> The problem is that those extensions require boiling the ocean. For
> that new type of collection to be used both the client and server need
> to be programmed to understand the extension. Both client and server
> need to be programmed with the new namespace and elements and what
> they are supposed to mean. And then if any of that information gets
> syndicated then all the aggregators will need to be upgraded. That's a
> serious about of ocean boiling.

Well, SixApart uses only "Simple Metadata Elements", which should (that's
a request to implementors) be provided out of the box by any APP client
(when authoring your entry, choose the "Advanced Edit..." menu item or
toolbar button and the "Advanced Property Editor" window opens; similar to
the equally-named window in Thunderbird that allows you to edit (X)HTML
attributes on links or images).

And when the content is syndicated, the server can apply some microformat
or any transformation to the entry content (e.g. include the book cover
thumbnail and a link to buy the book on Amazon inside the entry content)
and keep or discard the extension elements.

If a server doesn't process the extended metadata, the client will not use
it or will include the book cover thumbnail an "buy on Amazon" link
itself. What we need is a mean for the server to tell clients "when you
POST an entry in this collection, these are the extensions that I process
to deliver extended content" with a list of namespaces.
In a near future, APP user agents will be able to negotiate with APP
servers whether they support the "book" extension and then decide whether
they include the extension elements and let the server make the "extended
content", or they make the "extended content" themselves (connecting to
Amazon, etc.) using some microformat in the way you're suggesting here.

So, what we need is a mean for the server to communicate about special
processing of extensions in an Entry Collection. Something like:
<app:collection contents="entry" title="Books I've read" href="..."
     use-extensions="http://sixapart.com/atom/book#
http://purl.org/NET/RVW/0.1/value"; />

-- 
Thomas Broyer