Subject: Hierarchy / Containment

From: Julian Reschke <[email-masked]>
Date: Tue, 12 May 2009 12:20:32 +0200

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

---

From: Nikunj Mehta <[email-masked]>
Date: Tue, 12 May 2009 11:28:14 -0700

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:

> 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.

> A naive approach would be this (deliberately using new relation  
> names for now):
>
> 3) Exposed by atom:link/@rel=containedby element in the feed or  
> entry element.
>

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 May 2009 14:11:36 +0200

Hi Nikunj,

Nikunj Mehta wrote:
> ...
> 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?

>> 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).
> 

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:
> 
> 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).

BR, Julian

---

From: Nikunj Mehta <[email-masked]>
Date: Wed, 13 May 2009 09:21:59 -0700

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.
>

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.

>>> 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.
>
>> 2. Some collections accept only "entries that represent a  
>> collection", some disallow such entries, and yet others don't place  
>> any such restrictions.
> 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?