Hi Julian,
Your analysis of requirements is pretty good, although I would add
some things to make it complete.
On May 12, 2009, at 3:20 AM, Julian Reschke wrote:
Hi,
I have to admit that I haven't looked closely yet at the various
proposals to map collections to the Atom Feed Format (Nikunj's
draft, and the CMIS spec). But maybe that's a good thing, because I
have the feeling that both proposals make things more complicated
then they really should be for simple cases (of course I may be
missing something important, in which you'll tell me :-).
Simplicity is in the eye of the beholder - hierarchy-ID only defines
two new values for rel and one new attribute (with two possible
values) to go on an existing AtomPub element. It just restates a few
unclear parts of the AtomPub spec for discovering collections from
feeds which is painful if using service documents.
So, what containment are we talking about?
I am glad we are beginning to talk about "containment" as that is a
new aspect we are all trying to add to Atom/AtomPub.
- The containment model people are most familiar with is the file
system tree, with files and folders, and hierarchical naming.
- Many systems allow multiple containment, by supporting aliasing
(hard links in POSIX, additional bindings in WebDAV (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-23.html
>).
Some systems deal with multiple children types as well. CMIS shows a
good number of such examples where a single folder entry can have
children of four different kinds - policies, relationships, documents,
and descendants [1]. In another example, a Netflix title entry can
have children of 7 different kinds - awards, directors, cast, screen
formats, episodes, seasons, languages [2]. Each different kind leads
to its own feed/collection.
- Systems that do not support hierarchical names, or which do
support multiple containment, will need an explicit way to find the
parents of a resource (otherwise the implicit containment based on
the path names is sufficient).
No assumption can be made regarding namespaces in AtomPub as that is
managed by the server. A client cannot be constructing new URLs using
formulaic techniques.
So, what's needed to map this to Atom, starting with just the format
(read-only access)?
1) A way to discover that an Atom entry represents a collection
("contains" other entries).
2) A way to discover the contents of a collection.
3) Discover the collection(s) that contain a given Atom entry.
A naive approach would be this (deliberately using new relation
names for now):
1) An atom entry with an atom:link/@rel=contains element is a
collection; for Atom, that would link to a feed resource.
2) The entries of the feed identified above.
3) Exposed by atom:link/@rel=containedby element in the feed or
entry element.
Does it really need to be more complicated than that?
If you are interested in read-write access, then additional
requirements are:
1. How do you discover the collection from a feed?
2. Some collections accept only "entries that represent a collection",
some disallow such entries, and yet others don't place any such
restrictions.
3. What is the meaning of DELETEing an "entry that represents a
collection", especially when its entries may be hard-linked in to
other such entries?
[1] http://www.oasis-open.org/committees/download.php/32171/
[2] http://developer.netflix.com/docs/REST_API_Conventions
