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 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
