Joe,
Thanks for your comments on my comments ;-)
>> While we could create a whole series of "entry",
>> "generic", and other types, it might be better to
>> consider listing for each collection, the
acceptable
>> Content-Types.
>>
>
>This document is just the 'basic' protocol, where we
are describing
>the basic mechanisms and collection types. We are
>expecting to produce
>a further specification that covers editing
>collections of other types
>of documents, such as templates, etc.
In the current specification draft (04), it looks like
the "entry" and "generic" both specify identical
actions (in the table showing Body/No body versus
GET/PUT/DELETE/POST. So the real difference between
the two is in the Content-types that each can handle:
"generic" is unspecified, while "entry" is
only defined as "application/atom+xml" or
"application/soap+xml". In addition, the PROTOCOL
specifies which ATOM elements are Roundtrip.
The advantage of specifying Content-Types as opposed
to contents attribute of "entry" and "generic" (and
further definitions):
1) immediately gain the ability of the client to
discern acceptable Content-Types, something sorely
missing from the current specification.
2) immediately gain the advantage of the client being
able to determine if it can "talk" to the ATOM URI.
(Graphic applications can "talk" to ATOM APP that
accept "image/*", audio applications="audio/*", etc)
3) Do not have to amend a specification (or create a
new one) in order to handle every single Content-Type.
4) Adding different Content-Types to the allowable
formats immediately opens the specification to a wide
range of fairly obvious uses in the podcasting,
videocasting, *casting. And even in corporate use,
building in the parsing of Content-Types makes
available any kind of syndicated content whatsoever
using the same tools built around the APP
specification.
The current use of "contents" attribute still may have
its place (in resolving duplicate Content-Type
applications such as application/atom+xml templates
vs. application/atom+xml entries -- but I'm not fully
convinced of this example, however, there may be
others).
And then to cover the other specification listed under
contents="entry": you could specify that all
application/atom+xml entries provide Roundtrip
atom:updated and atom:id elements. I don't *think*
that this would adversly impact other uses of atom or
APP.
Again, just thoughts that I'm happy to debate. I don't
want to step on anyone's toes here.
Greg Smith
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
