Re: Recap - call for preferences/discussion - Re: New Version Notification for draft-divilly-atom-hierarchy-00

[Al Brown <[e-mail]>]

>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 [phone]
Email  [e-mail]
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" <[e-mail]>                                                                       
                                                                                                                                
  To:         Al Brown/Costa Mesa/IBM@IBMUS                                                                                     
                                                                                                                                
  Cc:         Atom-Syntax Syntax <[e-mail]>, James M Snell/Fresno/IBM@IBMUS, Julian Reschke <[e-mail]>, 
              [e-mail], Peter Keane <[e-mail]>, Sam Ruby/Raleigh/IBM@IBMUS, Ryan Mcveigh                 
              <[e-mail]>                                                                                         
                                                                                                                                
  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