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 :-).
So, what containment are we talking about?
- 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>).
- 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).
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?
BR, Julian
