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
