Re: New Version Notification for draft-divilly-atompub-hierarchy-00

[Nikunj Mehta <nikunj.mehta@xxxxxxxxxx>]

I have a new blog post about the main issues with CMIS in the areas  
where there is an overlap with hierarchy-ID [1]. Here is the summary:

• Link relations defined by CMIS cannot be used by a client that does  
not understand CMIS. So if you would like to have parent-child  
relations but don't want to put a cmis:idattribute (yes, that is a  
SHOULD level requirement), then you are out of luck. On the contrary,  
rel=master and rel=detail from hierarchy-ID do not impose any  
additional requirements.
• There is no way to auto-discover the POST url for a feed. For  
example, you obtained a list of documents in a folder and now want to  
add another document to that folder. Without understanding  
rel=repository and cmis:collectionType, there is no way to do that. On  
the contrary, hierarchy-ID will be understood even by existing AtomPub  
clients, and these clients will be able to add another item next to  
the existing document.
• The CMIS spec defines PUT and DELETE methods on an atom:feed type  
resource (yes, see Section 3.4.5.4 and 3.4.5.6). I would imagine that  
the CMIS spec would need to go to IETF for doing something like this  
because they are in effect extending the semantics of the application/ 
atom+xml;type=feed MIME type. No such extraordinary extension is going  
on in hierarchy-ID and this ID is before the IETF for consideration.

Nikunj
blog: http://o-micron.blogspot.com

[1] http://o-micron.blogspot.com/2009/05/cmis-vs-atompub-hierarchy-i-d.html

On May 6, 2009, at 10:21 AM, Nikunj Mehta wrote:

> There is a good chance we will harmonize the names and semantics of  
> the link relations and h:role attribute between the hierarchy I-D  
> and CMIS. However, I want to clarify that the hierarchy-ID doesn't  
> define entry types in a way that can be compared with CMIS entry  
> types directly.
>
> The h:role concept is used only in the app:collection elements to  
> control publishing of new entries only. On the contrary, CMIS  
> specifies hard typing for entries that stays with the entry for as  
> long as it is alive.
>
> Moreover, CMIS entries are not always represented as Atom entries.  
> For example, from the CMIS spec v0.61c1 Section 3.4.5.4 states that
>
> A folder entry "is exposed as a feed.  The properties of a folder  
> map onto the feed tag."
>
> Likewise, Section 3.4.5.6 states that
>
> A policy entry "is exposed via ‘policies’ as a feed."
>
> This spec even defines behavior for the PUT and DELETE method on an  
> atom:feed type resource.
>
> The idea with hierarchy I-D is to offer a simpler hierarchy model  
> that assists in managing AtomPub resources without any baggage of a  
> full-fledged content management system. The benefit of this is in  
> systems that do not satisfy the MUST level requirements of CMIS, but  
> still want hierarchy.
>
> Nikunj
> On May 6, 2009, at 8:56 AM, Peter Keane wrote:
>
> > On Wed, May 6, 2009 at 5:01 AM, Julian Reschke  
> > <julian.reschke@xxxxxx> wrote:
> > > Nikunj Mehta wrote:
> > > > We would like to solicit the group's feedback on this I-D. There is
> > > > already some interest both internally at Oracle and from other  
> > > > parties in
> > > > advancing this I-D along standards track.
> > > > ...
> > >
> > > I note that there is overlap with the AtomPub bindings in CMIS (see
> > > <http://www.oasis-open.org/committees/download.php/32171/Draft%2061.zip 
> > > >),
> > > and I think it would be totally great if we could find out whether  
> > > a single
> > > set of extensions would be sufficient.
> >
> > While I see some overlap, it seems like the use cases are quite
> > different (hierarchy in CMIS is just a small part of a much larger
> > goal).  I see some overlap in a couple of link@rels and it seems the
> > 'h:role' extension in hierarchy-ID is analogous to 'type' in CMIS.  I
> > could see some benefit in harmonizing names where that makes sense.
> >
> > CMIS new link relation types:
> > parents
> > repository
> > children
> > descendents
> > allowableactions
> > allversions
> > latestversion
> > relationships
> > type
> > source
> > target
> > stream
> > policies
> > pwc
> >
> > CMIS entry types:
> > type
> > document
> > folder
> > relationship
> > policy
> > (also two new mime types: for query doc & allowable actions doc)
> >
> > hierarchy-ID new link relation types:
> > master
> > detail
> >
> > hierarchy-ID entry types:
> > h:role=master
> > h:role=detail
> >
> > (happy to be corrected if I got any of that wrong)
> >
> > --peter keane
> >
> >
> >
> >
> > > BR, Julian