Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-00

From: Al Brown <[email-masked]>
Date: Wed, 27 May 2009 06:59:09 -0600

I agree with Julian.  Here's a technical reason:

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 am not sure I want to suggest servers should precalculate/prefetch the value of a link before (if?) The client requests it.

I believe this sets a bad precendent and at the same time does not really fit cmis' use case.
Sent from BlackBerry.

----- Original Message -----
From: Julian Reschke [[email-masked]]
Sent: 05/27/2009 02:12 PM ZE2
To: "Nikunj R. Mehta" <[email-masked]>
Cc: Atom-Syntax Syntax <[email-masked]>
Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-00

Nikunj R. Mehta wrote:
> On May 25, 2009, at 8:42 AM, Julian Reschke wrote:
> 
>> with respect to 
>> <http://tools.ietf.org/html/draft-divilly-atom-hierarchy-00#section-3>, 
>> "Inline Representation of Hierarchical Resources"...
>>
>> It seems to be that using atom:link as a container elements stretches 
>> its semantics of "reference from an entry or feed to a Web resource" 
>> too much.
> 
> I don't agree with that. A previous discussion on this mailing list more 
> than a year ago [1] has already concluded that it is perfectly legal to 
> do so. Additionally, the hierarchy-ID approach appears similar to the 

I do not agree with that conclusion, but nevertheless, just because 
something is syntactically legal doesn't make it a good choice.

atom:link is defined to as:

   "The "atom:link" element defines a reference from an entry or feed to 
a Web resource."

Inlining the content of referenced web resource is IMHO contrary to that 
definition.

> approach taken by the RFC4287 with atom:content usage models, where 
> several options about inline and out-of-line content delivery are 
> available.

But atom:content has been explicitly designed that way:

   "The "atom:content" element either contains or links to the content 
of the entry." -- 
<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.1.3>

while atom:link has not.

So I'll stick with my comment that atom:entry is better suited for that 
purpose, being defined as:

    "The "atom:entry" element represents an individual entry, acting as 
a container for metadata and data associated with the entry." -- 
<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.1.2>

>> As Al pointed out on the CMIS mailing list 
>> (<http://lists.oasis-open.org/archives/cmis/200905/msg00186.html>), it 
>> may be better to use a container element inside atom:entry.
>>
>> So, the example in 
>> <http://tools.ietf.org/html/draft-divilly-atom-hierarchy-00#section-3.2.3>: 
>>
>>
>>   <atom:entry>
>>     <atom:link rel="down"
>>       href="/finance/feeds/default/portfolios/1/positions">
>>       <atom:feed>
>>         <atom:link rel="self"
>>          href="/finance/feeds/default/portfolios/1/positions"/>
>>          ...
>>       </atom:feed>
>>     </atom:link>
>>     ...
>>   </atom:entry>
>>
>>
 > ...

BTW: the format above is currently forbidden by the RNC (because of the 
use of the atom namespace for the contained element); I know that part 
of the spec is informative, but still...

BR, Julian

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Thu, 28 May 2009 12:00:50 -0700

Would the purported server be stupid enough to inline both descendants  
and children, knowing fully well that the former subsumes the latter?

Can you clarify what you mean by "servers should precalculate/prefetch  
the value of a link before". What is provided in the hierarchy-ID is  
merely a syntactic definition for the presence of a feed or entry  
element inside the link element. There is no question that the spec  
requires servers to behave in this way. A server may for whatever  
reason choose to do so. In fact Google's APIs as well as Netflix's too  
often inline nested data when they think a client may benefit. So in  
that way, this I-D does not in any way create a precedent. It has  
already been done, for worse or better.

Whether CMIS chooses to adopt this path, there are numerous benefits  
to this approach that I have described in several previous messages  
without any clear argument against, except stylistic, or presumed but  
non-existent conformance issues. If there are substantive technical  
merits to an alternative approach, I am all ears and would love to  
incorporate them in to the I-D.

As always, I appreciate any and all feedback, including that which may  
not necessarily be accurate.

Nikunj
http://o-micron.blogspot.com

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.
>
> I am not sure I want to suggest servers should precalculate/prefetch  
> the value of a link before (if?) The client requests it.
>
>>> <http://tools.ietf.org/html/draft-divilly-atom-hierarchy-00#section-3 
>>> >,
>>> <http://tools.ietf.org/html/draft-divilly-atom-hierarchy-00#section-3.2.3 
>>> >:
>>>
>>>
>>>  <atom:entry>
>>>    <atom:link rel="down"