On May 13, 2009, at 5:11 AM, Julian Reschke wrote:
Hi Nikunj,
Nikunj Mehta wrote:
...
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.
Understood.
Many systems deal with this by putting all children into the same
container, and just distinguish by MIME type. Or my assigning
subfolders.
So does this require multiple *different* children feeds?
Both examples I gave here indeed require 'different' feeds. CMIS
identifies each feed through a separate link rel value and a distinct
href. Netflix does not provide an out of line feed, but houses each
subfolder in a separate foreign markup element.
- 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.
Indeed. I just wanted to clarify that this is the main difference
from a filesystem's (or WebDAV's) containment model.
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?
...
DELETE as specified in HTTP/1.1 (RFC 2616) really leaves this open.
WebDAV (RFC 4918) defines a specific hierarchical containment model,
but still leaves this to the server. WebDAV BIND (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-23.html
>) introduces the necessary terminology for this, and clarifies that
DELETEing something from a collection will not affect other paths to
the resource (as long as these are really distinct paths).
Atom doesn't currently define any such model and namespace decisions
are server's decision. Doesn't that lead to interoperability problems?
