There is precedence to the proposal I have submitted. GData uses
feedLink [1] and entryLink [2] mechanisms in Google's own namespace to
include in-line representations of entries and feeds. Notice how these
elements have both @rel and @href, critical to the functioning of
Atom's own link mechanisms.
The atom-hierarchy-ID is merely trying to standardize such behavior
and not invent new behavior. Moreover, the proposed syntax is not
merely syntactically legal, it is also semantically valuable. There
are three benefits to this approach:
1. The context of the inlined feed or entry is immediately clear from
the @rel value
2. The server can choose to inline content as per requirements and
configuration
3. The format supports inlining of any number of entries - a single or
multiple. It also expresses the absence of any entries, when this is
required.
Which of these advantages can you claim for directly embedding an
entry inside another?
Nikunj
http://o-micron.blogspot.com
On May 27, 2009, at 5:12 AM, Julian Reschke wrote:
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.
I respectfully disagree although you are entitled to your opinion.
Previous discussion on this mailing list [3], which included several
people who were part of the early crowd of atom-syntax, has made it
clear that one should not go by any prejudice about the lack of
specification of a certain previously undefined mark up usage.
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...
Again, you are misleading the reader to assume that RNC schema is
normative. There is a very good reason for it to not be normative and
the spec editors were clear about them.
Nikunj
[1] http://code.google.com/apis/gdata/elements.html#gdFeedLink
[2] http://code.google.com/apis/gdata/elements.html#gdEntryLink
[3] http://www.imc.org/atom-syntax/mail-archive/msg20456.html
