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 protected]]
Sent: 05/27/2009 02:12 PM ZE2
To: "Nikunj R. Mehta" <[email protected]>
Cc: Atom-Syntax Syntax <[email protected]>
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
