On Thu, Jun 4, 2009 at 11:15 AM, Nikunj R. Mehta <[email protected]>wrote:
> On Jun 4, 2009, at 4:29 AM, Kyle Marvin wrote: > > FWIW, we have been looking at revising our strategy for inlining entity > references and have reached largely the same conclusion that you have > reached. The ideal model is not some new extension type (like > gd:entryLink/gd:feedLink) but rather a model that lets you nest the content > as an extension directly within a link element. > > > We have generic clients that consume the GData feeds and the use of > gd:feedLink and gd:entryLink does make it difficult to process inlining > since they are in a proprietary namespace. So a standard for in-lining will > be definitely help, especially if it is blessed by IETF. > > This way, clients who are unaware of the inlining extensions can still > process it as a regular reference (via the link) and follow it, albeit less > efficiently than if they just used the inlined content. I agree with > comments on this thread that if data is inlined inside of link, it is better > if it's done inside of an extension that clearly marks the content as being > the inlined data and avoids collisions with any any future link extensions. > > > > I had considered this approach [1] and am open to a specialized extension > such as ah:inline. I would, however, strongly refute the claim that the > atom:link element cannot be used for any inlining of content that a few on > this mailing list are advocating. > > > I'm not as enthusiastic about the idea of defining some inlining syntax > that is a peer of the atom:link as was suggested earlier (just put an entry > inside an entry) or later (ah:inline) on this thread. You then lose or > must duplicate the context (the "rel") that tells you the relationship of > the contained entity to the containing resource. You may even lose the > ability to know how to deference the inlined resource independently; there > are potential use cases where you might inline an XML entity that doesn't > have the equivalent of a 'self' link. It also means you have to > redundantly specify the content type of the inlined data to inform > processors when this information is may already available via > atom:link/@type. > > > These are all problems I have pointed out [2] earlier in the thread. So I > agree with your conclusions. > > > What seems apparent from this thread is that multiple existing large-scale > implementors leveraging the Atom Syntax are seeing a need for this and seem > to be converging on a roughly similar solution. As such, there's probably > significant benefit on proposing an extension that makes this unambiguous > and consistent across implementations so Atom clients can rely on it. We'd > certainly be supportive of such an extension but ideally it would be a > standalone draft for link inlining that's not directly tied to the hierarchy > use case that started this thread (but could certainly be leveraged by it) > > > It seems unwise to consider two separate I-Ds - one for specifying new link > @rel values and another to deal with in-lining. Will it buy us anything in > the IETF process? > It would get us a clear model for doing inlining that's valid beyond the specific use case of hierarchy which would be more useful to us since we don't have a specific need for the hierarchy I-D; as someone else stated earlier, we have many types of relations where inlining would be beneficial so the specifics of the spec is too narrow to support what we need. > Would you be interested in seeing this get on the experimental track so > that when it is time to consider a revision of Atom the experience > accumulated by then can be used to propose something along standards track? > I'm not opposed but if this is considered to be prior art that will drive how inlining should be done more generally, then I think the net effect (read as "the hoops you will have to jump through to get consensus") are going to be the same whether the inlining functionality is joined or split off so why not get the general solution's benefit for the effort. It could be there are aspects of this decision I'm missing. I understand that what I'm asking for is more work for you (or someone) and I'm sympathetic to that. > > > As Pablo notes, an inline extension can be a big latency win on first-fetch > use cases where there's a set of related resources and you don't want to do > multiple serialized round trips to get them all, but it also nicely > preserves the ability to allow subsequent interactions with the inlined > entities as independent HTTP resources using a model that Atom clients > already understand (link following). > > Cheers! > > -- Kyle Marvin > (Google GData Team) > > On Wed, Jun 3, 2009 at 3:30 PM, Pablo Castro > <[email protected]>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. >> >> 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 >> >> >> > [1] > http://o-micron.blogspot.com/2009/05/atom-multiple-links-with-same-rel-value.html > [2] > http://o-micron.blogspot.com/2009/05/cmis-xvi-perils-of-embedding-entry.html >
