Interesting. There's a solution that seems reasonable and is similar to what google did with feedLink[1] and you still get generic inlining. This also uses the traditional extension mechanism and does not, I believe, have the issues raised by Mark, Julian or I. This also could be done in an I-D without requiring a new WG.
Proposal: 1. New element, let's call it <ah:inline> 2. It supports the following attributes: rel (same as link rel; required); href (optional); etag (optional) 3. inline rel has the same semantics and constraints as link rel 4. if href is not specified, then it corresponds to the link with the same relation. If href is specified, it corresponds to the link with the same relation and href. 5. ah:inline supports any markup - atom, app, or other 6. ah:inline can be used in atom:entry or atom:feed and can have a cardinality 0..n In the example you posted, it would be: <atom:entry> ... > <link rel="related" type="application/atom+xml;type=entry" title="Venue" href="Events(456)/Venue"> > </link> > ... > <ah:inline rel="related" href="Events(456)/Venue"> > <entry m:type="EventsSample.Venue"> > <id>http://localhost:81/EventsSample/Venues(789)</id> > <title type="text"></title> > <updated>2008-02-17T03:01:18Z</updated> > <author> > <name /> > </author> > <link rel="edit" title="Venue" href="Venues(789)" /> > <link rel="related" type="application/atom+xml;type=entry" title="SalesContact" href="Venues(789)/SalesContact" /> > <content type="application/xml"> > <d:VenueID m:type="Int32">789</d:VenueID> > <d:Name>The Cool Place</d:Name> > <d:Description>Great place for parties!</d:Description> > <d:Capacity m:type="Int32">1500</d:Capacity> > <d:Type>Nightclub</d:Type> > </content> > </entry> > </ah:inline> </atom:entry> CMIS would then use it this way: <atom:entry> ... <link rel="down" href="/res1/down" type="application/atom +xml;type=feed" /> <link rel="down-tree" href="/res1/downtree" type="application/atom +xml;type=feed" /> ... <ah:inline rel="down"> <atom:feed> <atom:entry >...</atom:entry> ... </atom:feed> </ah:inline> </atom:entry> [1] http://code.google.com/apis/gdata/elements.html#gdFeedLink Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email [email protected] CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. From: Pablo Castro <[email protected]> To: "Nikunj R. Mehta" <[email protected]>, Mark Nottingham <[email protected]> Cc: Julian Reschke <[email protected]>, Atom-Syntax Syntax <[email protected]> Date: 06/03/2009 03:55 PM Subject: RE: New Version Notification for draft-divilly-atom-hierarchy-00 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. 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
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
