On Jun 3, 2009, at 3:30 PM, Pablo Castro wrote:
Sorry for coming late to the thread, somebody forwarded me this and
I thought I'd add a couple of comments from the Astoria (ADO.NET
Data Services) side.
Thanks for contributing to this thread. We have had little activity on
atom-syntax lately, but this topic did stir pretty strong reactions on
all sides. That can only indicate a strong desire to solve this
problem and arrive at a consensus so as to avoid fragmentation - I see
it as a good omen for a new RFC.
We have a similar need in Astoria to include inline content. This is
not for hierarchies, but more in general because the Astoria data
model consists basically of entities (mapped to entries) and
associations (mapped to links to entries or links to feeds depending
on the cardinality of the association-end). We needed to allow
clients to request a given entry and pre-fetch related entries (this
is mostly a round-trip optimization to help with latency, but it
also results in a couple of extra features in Astoria).
The link that Nikunj included below describes the reasoning in more
detail:
http://blogs.msdn.com/astoriateam/archive/2008/02/18/related-entries-and-feeds-links-and-link-expansion.aspx
We interpreted the Atom spec as saying that while the spec itself
didn't define any meaning for content inside the link element, it
didn't prohibit either. In order to avoid future conflicts with Atom
elements inside link, we ended up putting an <inline> element in our
own namespace immediately under link, and then an Atom entry or feed
in it. If the link points to something that hasn't been created yet
or that the user can't see due to security reasons, then we still
include the inline element, but it's empty. That way a client
processor can know that the link is expanded but there is no actual
resource at the other end of it.
Expanding the entry/feed inside the link element means that if we
have more than one expanded link we don't need to add any indication
of what entry extension element corresponds to what link, which we
would need if we included the inlined content as a peer of the link
element instead of as a child.
It's also easy for client parsers. We parse the link as usual
(extract url and such) and then if we see an inner element inline in
our namespace then we know the link was inlined.
There is of course the question of the risk of pulling down a giant
graph because of a client asking to expand too much. The most common
form of this issue is expanding long feeds inline inside another
entry. We actually use the usual Atom paging constructs even in
inlined feeds, so the server is free to include a few entries and
then a "next" link where the client can get more. This allows for a
good balance between low-latency first fetch to get and display data
and progressive retrieval of more data as needed.
We had a discussion about the topic of inline expansion some time
ago in this list also:
http://www.imc.org/atom-syntax/mail-archive/msg20444.html
-pablo
-----Original Message-----
From: [email protected] [mailto:[email protected]
] On Behalf Of Nikunj R. Mehta
Sent: Wednesday, June 03, 2009 9:43 AM
To: Mark Nottingham
Cc: Julian Reschke; Atom-Syntax Syntax
Subject: Re: New Version Notification for draft-divilly-atom-
hierarchy-00
On Jun 2, 2009, at 6:28 PM, Mark Nottingham wrote:
On 27/05/2009, at 10:12 PM, Julian Reschke wrote:
I do not agree with that conclusion, but nevertheless, just because
something is syntactically legal doesn't make it a good choice.
+1 - the clearest way to communicate what's going on here is to use
a new child element.
Assuming that the contents of the link element are inlined content
are adding an extension without explicitly identifying it; this may
conflict with future uses. There isn't a way for an Atom processor
to inspect a link element and know that the content is inlined; they
have to guess that this specification is in effect, therefore the
link content is the inlined content. This isn't good practice.
Just FYI, Joe Gregorio and by implication Google supports directly
embedding atom:content inside atom:link. See the last comment on [1].
I don't know what we mean by practice here, but that is exactly what
is going on in lots of places.
Nikunj
http://o-micron.blogspot.com
[1]
http://blogs.msdn.com/astoriateam/archive/2008/02/18/related-entries-and-feeds-links-and-link-expansion.aspx#8573352
