On Jun 2, 2009, at 10:58 AM, Al Brown wrote:
#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 you would not be the first person to have committed this mistake.
On Jun 2, 2009, at 2:29 PM, Al Brown wrote:
how should we proceed to expose a set of sets of documents?
If you research the atom-syntax ML as well blog postts related to hierarchy in Atom, you would see Dare Obasanjo griping about AtomPub's lack of support for "hierarchical data inlining" [1] and Microsoft's justification for Web3S [2], which spawned a discussion about whether Atom could deal with recursive structures such as a hierarchy. Microsoft subsequently rolled back their plans and instead switched to using Atom as is [3]. Joe Gregorio eloquently refuted claims that Atom syntax is inappropriate for hierarchies [4] by, essentially, advocating its hypertext mechanisms, which is exactly what the atom- hierarchy I-D is proposing [5].
Quoting James Snell [6] 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.
It would be unfortunate if you have not received this advice from James directly. It would have spared all of us quite some grief.
If you are right, perhaps the atom-syntax group, Microsoft, IBM, or Google would have included your approach in their APIs. I can only guess, having hung around here 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 you are right in what you are doing. We'll leave it for the future to decide.
Nikunj http://o-micron.blogspot.com [1] http://www.25hoursaday.com/weblog/2007/06/09/WhyGDataAPPFailsAsAGeneralPurposeEditingProtocolForTheWeb.aspx [2] http://www.25hoursaday.com/weblog/CommentView.aspx?guid=020611C4-F53C-4DF0-8DB0-9A050DD6CD9C [3] http://www.25hoursaday.com/weblog/2008/02/28/WindowsLivePlatformNewsMicrosoftStandardizesOnAtomPubForWebServicesAndOtherStories.aspx [4] http://bitworking.org/news/197/In-which-we-narrowly-save-Dare-from-inventing-his-own-publishing-protocol [5] http://www.ietf.org/internet-drafts/draft-divilly-atom-hierarchy-00.txt [6] http://www.snellspace.com/wp/?p=681
