>I'd also like to think of the CMIS TC and its spec editors as open to honest discussions based on technical merits. It doesn't help to systematically mislead the >community as has been the case. Please coordinate with Ryan and the rest of the Oracle standards team on CMIS. Knowing them, they will do quite well with your feedback and make sure the TC acts on it. They are a very talented and responsive team.
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: Atom-Syntax Syntax <[email protected]>, James M Snell/Fresno/i...@ibmus, Julian Reschke <[email protected]>, [email protected], Peter Keane <[email protected]>, Sam Ruby/Raleigh/i...@ibmus, Ryan Mcveigh <[email protected]> Date: 06/03/2009 09:51 AM Subject: Re: Recap - call for preferences/discussion - Re: New Version Notification for draft-divilly-atom-hierarchy-00 On Jun 2, 2009, at 5:19 PM, Al Brown wrote: The main reason we need trees in this protocol is the ability to retrieve the tree in 1 round-trip. The atom-hierarchy I-D meets this requirement as demonstrated in the I-D text. Why wouldn't CMIS want to be a good atom citizen? The burden of proof is not on me. And besides, we have been through this with a big software company before that was trying to upstage AtomPub by simply spreading mis-truths. 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. I'd also like to think of the CMIS TC and its spec editors as open to honest discussions based on technical merits. It doesn't help to systematically mislead the community as has been the case. Let me cite some instances. On May 27, 2009, at 5:59 AM, Al Brown wrote: I have an atom:entry in a hierarchy. It has down and down-tree. The document also wants to display a heirarchy. If I use link to show the hierarchy, I will have duplicate resources in both links - one level in down and one to n levels in down-tree. If the hierarchy is outside link and in atom:entry, then there is no duplication. I pointed out how this is a fatally flawed conclusion [1]. On May 27, 2009, at 8:36 AM, Al Brown wrote: I, personally, think there is an alternative that does not have the semantic conflict Julian mentioned nor the performance / caching issues with prefetching the link and including. There are none. A client can use this information as an optimization, not as the exact representation, just like atom:entry inside atom:feed. 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. I refuted this claim above. The use case is simple enough to be addressed in many different ways, including atom-hierarchy-ID. On Jun 2, 2009, at 5:19 PM, Al Brown wrote: 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. You seem to be uninterested in investigating other's experiences in dealing with hierarchy and in-lining. Please read up on Astoria or ADO.NET Data Services [2]. I quote from the referenced article Using AtomPub constructs and extensibility mechanisms to enable Astoria features: Inline expansion of links (“GET a given entry and all the entries related through this named link”, how we represent a request and the answer to such a request in Atom?). The exact mechanism for in-lining expanded links is exactly as specified in atom-hierarchy-ID [3]. Nikunj http://o-micron.blogspot.com [1] http://www.imc.org/atom-syntax/mail-archive/msg21041.html [2] http://carnage4life.spaces.live.com/Blog/cns!616444EE7A34F417!2324.entry [3] http://blogs.msdn.com/astoriateam/archive/2008/02/18/related-entries-and-feeds-links-and-link-expansion.aspx
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
