The main reason we need trees in this protocol is the ability to retrieve the tree in 1 round-trip. If we use N round-trips, entries and feeds are sufficient per James' info below. Almost all ECM systems support this capability to retrieve a tree and it is important to the TC to represent it. Folder navigation is a large part of the API set clients use. All the vendors have learned the hard way that it is very important to have folder navigation perform well. Returning a tree was the common optimization most vendors provided. If it was an option to not expose, the cmis tc, would not have gone through the effort to date.
Also, AFAIK, nobody has tried to support the ECM use-cases with Atom and APP before CMIS. CMIS is the first. All the advice we have gotten, from all the sources, we have adopted and worked through. Why wouldn't CMIS want to be a good atom citizen? In the future, please keep the tone non-combative and focused on technical aspects. I'd like to think the atom community as welcoming and supportive. Best, -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email [email protected] CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. From: "Nikunj R. Mehta" <[email protected]> To: Al Brown/Costa Mesa/i...@ibmus Cc: Peter Keane <[email protected]>, Atom-Syntax Syntax <[email protected]>, James M Snell/Fresno/i...@ibmus, Julian Reschke <[email protected]>, [email protected], [email protected], Sam Ruby/Raleigh/i...@ibmus Date: 06/02/2009 03:31 PM Subject: Re: Recap - call for preferences/discussion - Re: New Version Notification for draft-divilly-atom-hierarchy-00 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
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
