CMIS XVI: Ignore good hypertext practices at your own risk

The spec lead for CMIS AtomPub extensions simply doesn't have the patience to get his protocol right. Feedback is either too minor for his current attention or pretty much useless for his needs. Let me give an example for each.

When asked about a number of optional RFC5023 things that are never referenced by CMIS, such as those in CMIS XIV: Can't do basic path manipulation? Don't blame AtomPub, Al takes refuge in the W-I-P tent. 

On the other hand, Al Brown is dead set against using entry inside link elements for in-lining hierarchy representations. I am beginning to get that his opposition is often not well-intentioned and that the CMIS TC members are nodding their heads without fully realizing the consequences of doing so.

#1 does not ideally address CMIS' use case of how to represent a tree of atom entries in a single document but rather provide a generic pre-fetching/inlining mechanism.

This appears rather cavalier to me. But this would not be the time someone did so. Some of you would remember Dare Obasanjo and Yaron Goland griping about AtomPub's lack of support for "hierarchical data inlining" and Microsoft's justification for Web3S as a brand new publishing protocol for the Web , which spawned a discussion about whether Atom could deal with recursive structures such as a hierarchy. Joe Gregorio eloquently refuted claims that Atom syntax is not suitable for hierarchies by, essentially, advocating its hypertext mechanisms, which is exactly what the atom-hierarchy I-D is proposing.

Quoting James Snell about how he dealt with hierarchy in IBM Lotus Connections:

In reality, it turns out that hierarchy in APP is actually quite simple to achieve. The IBM Lotus Connections product includes a component called “Activities” which has a very hierarchical data structure. Every user has a set of collections, each of which has a set of entries, each of which can have any number of comments that can be nested to any depth. When I first designed the Atom Publishing Protocol API for activities, I created a top level collection of Activities. Every entry in this collection represents an Activity. Every activity is also a collection. I post entries and comments to the activity collection using the standardized Atom Threading Extension to provide the additional hierarchy. An Atom Entry can represent pretty much anything, including a collection of Atom entries.

At IBM we’ve look at pretty much all of these issues and found simple approaches to resolving them that fit perfectly well within the bounds of the Atom specs. We’re using APP for a lot of different things, not all of which fall neatly into the original use cases APP was intended to cover. Yes, we had to give certain aspects some careful thought but we generally could not find any showstoppers.

Microsoft subsequently rolled back their plans and gave up on Web3S and instead switched to using Atom as is. 

If Al is right are right, perhaps the atom-syntax group, Microsoft, IBM, or Google would have defined the meaning of atom:entry inside atom:entry, which appears natural to Al, and included it in their APIs. I can only guess, having hung around atom-syntax and atom-protocol for the last 3 years, that in-lining an entire hierarchy was not a good hypertext-based protocol design approach, just like HTML does not inline all its CSS, images, JS, and embedded objects.

Perhaps all this evidence will make you see why the approach proposed in atom-hierarchy I-D is suitable for what you are trying to achieve. But perhaps CMIS is right in what it is doing. Quoting Joe from the earlier referenced post:

no one has found the one true hierarchy to rule them all

We'll leave it for the future to decide.