Re: New Version Notification for draft-divilly-atom-hierarchy-01

["Nikunj R. Mehta" <[e-mail]>]

On Jun 8, 2009, at 3:44 PM, Al Brown wrote:

> Nikunj wrote:
> >	Al Brown wrote:
>
> b. add a new attribute to link that specifies if they are inlined
> (down) <link rel="down" href="http://www.example.com/foo/down" />
> (down-tree) <link rel="down" ah:inlined="true" href="http://www.example.com/foo/down/inlined 
> " />
> This adds complexity if there are cardinality constraints on link  
> relations such as alternate and clients not aware of I-D may think  
> they are the same.
> >IMHO, ah:inlined does nothing because the presence of ae:inline  
> makes it plenty clear. If you were trying to say that there is a  
> certain level of depth in the tree, may >be an attribute would help,  
> but even then you don't know what things the server may have elided  
> from every entry. So, bottom line is, there is not much value to an  
> >attribute to describe the thing that is in-lined. You are best off  
> using what you have received as an approximation and then get the  
> exact representation if you care so >much in a separate network  
> call. Of course, out-of-band communication or specialized mark-up  
> may provide enough information for you to avoid such round-trips.
> Maybe I did not explain clearly enough - this is a protocol/ 
> hypermedia issue. How does the client say (follow the right link  
> relation) I want an inlined representation of this resource  
> specified by a link relation? E.g.,
>
The question is clearly phrased this time and I understand the  
intention. However, as I said in the previous message, modulo hreflang  
and type,

Atom does not provide any means of advertising URIs for retrieving  
representation variants. This could be a source of your  
dissatisfaction but it applies equally well regardless of hierarchy or  
in-lining.
> Client (C) navigates to this atom entry (A) somehow. A wants to  
> advertise to the client that A has references to two to  
> representations for resource B.  One version of B is flat (ala a  
> feed). One version of B is the same flat feed with its link  
> relations inlined (ala tree).
>
> How can resource A provide the client C with information there are  
> two choices available for B (flat vs tree)?
>
Perhaps James Snell's template idea may be worth considering. I don't  
know yet.
> -Al
>
>
> 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 [phone]
> Email [e-mail]
> 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.
>
> <graycol.gif>"Nikunj R. Mehta" ---06/08/2009 03:33:06 PM---As I see  
> it, whether there is a @rel=down-tree or not, you would have to  
> communicate certain information out-of-band, e.g., dep
>
> <ecblank.gif>
> From:	<ecblank.gif>
> "Nikunj R. Mehta" <[e-mail]>
> <ecblank.gif>
> To:	<ecblank.gif>
> Al Brown/Costa Mesa/IBM@IBMUS
> <ecblank.gif>
> Cc:	<ecblank.gif>
> James M Snell <[e-mail]>, atom-syntax Syntax <[e-mail] 
> >
> <ecblank.gif>
> Date:	<ecblank.gif>
> 06/08/2009 03:33 PM
> <ecblank.gif>
> Subject:	<ecblank.gif>
> Re: New Version Notification for draft-divilly-atom-hierarchy-01
>
>
>
> As I see it, whether there is a @rel=down-tree or not, you would  
> have to communicate certain information out-of-band, e.g., depth of  
> the tree or the level of completeness in every in-lined entry.
>
> Atom does not provide any means of advertising URIs for retrieving  
> representation variants. This could be a source of your  
> dissatisfaction but it applies equally well regardless of hierarchy  
> or in-lining.
>
> On Jun 8, 2009, at 3:11 PM, Al Brown wrote:
> James wrote:
> >Hmmm.... I know we've discussed this, but after thinking about it  
> more
> >and looking through the examples, I'm becoming increasingly less
> >convinced that we need a distinction between "down" and "down-tree".
> >One should simply assume that "down" could point to a child entry or
> >child feed and that those children could potentially also be parents.
> >Yes, that possibly increases the processing compexity but I think it
> >simplifies the model overall.
>
> We've discussed this today on the phone.  For me this is a  
> difference of protocol/hypermedia vs. syntax.  For syntax, "down"  
> and "up" are sufficient.  A flat model can modeled with feed and a  
> tree can be modeled using generic inlining in a feed or entry.
>
> A client requests an atom document - entry or feed.  How does the  
> server advertise to the client, via what is in the atom document,  
> here are two links to representations (flat vs. tree) of a resource,  
> e.g. the folder's children:  one link returns a flat list (no  
> inlining) and one link returns a tree (inlined).
> It is no different from seeing an HTML vs. a PDF representation of  
> the same blog entry. One gives you a lot of context such as  
> comments, related posts, advertisements and the like, and the other  
> may be limited. This problem, AFAICT, exists regardless of CMIS or  
> hierarchy.
> Both are the same document just with or without inlining of linked  
> resources of a particular link relation.
> For all practical purposes, they are different documents, i.e.,  
> different representations of a single resource.
> Since the resources are crossing the wire, the first resource (e.g.,  
> folder) needs to convey how access a hierarchical resource (e.g.,  
> items in a folder) in either a flat mode (feed) or tree (feed with  
> inlined resources).
>
> The options I see are:
> a. append -tree to link relations that may inline (e.g., down-tree,  
> up-tree). Not so nice, but works.
> It may not be specific enough anyway to say this is a tree link  
> because it says nothing about depth
> b. add a new attribute to link that specifies if they are inlined
> (down) <link rel="down" href="http://www.example.com/foo/down" />
> (down-tree) <link rel="down" ah:inlined="true" href="http://www.example.com/foo/down/inlined 
> " />
> This adds complexity if there are cardinality constraints on link  
> relations such as alternate and clients not aware of I-D may think  
> they are the same.
> IMHO, ah:inlined does nothing because the presence of ae:inline  
> makes it plenty clear. If you were trying to say that there is a  
> certain level of depth in the tree, may be an attribute would help,  
> but even then you don't know what things the server may have elided  
> from every entry. So, bottom line is, there is not much value to an  
> attribute to describe the thing that is in-lined. You are best off  
> using what you have received as an approximation and then get the  
> exact representation if you care so much in a separate network call.  
> Of course, out-of-band communication or specialized mark-up may  
> provide enough information for you to avoid such round-trips.
> c. leverage link templates rather than link relations
> I am not aware of "link templates". If you are referring to draft- 
> gregorio-uri-templates, then too there is no notion of templates  
> baked in to the link element yet.
> d. use out of band communication - append a uri argument such as  
> includeLinkRel=down to the URI of the resource; could also be HTTP  
> header. Not very RESTful but works.
>
> If the model is not sufficient to convey to the client here's a flat  
> mode vs. here's a tree mode, CMIS will have to find another  
> alternative as it is currently required by the CMIS domain model.
>
> I see the options for CMIS as:
> 1. Leverage the model specified by the I-D if exists (best)
> 2. Move down-tree to CMIS namespace. This does not solve the  
> protocol/hypermedia problem for anybody else.
> 3. Specify in the CMIS specification an URI argument to enable  
> inlining of 'down'.
>
> -Al
>
> 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 [phone]
> Email [e-mail]
> 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.
>
> <graycol.gif>James M Snell ---06/08/2009 11:55:37 AM---Comments  
> below...
> <ecblank.gif>
> From:	<ecblank.gif>
> James M Snell <[e-mail]>
> <ecblank.gif>
> To:	<ecblank.gif>
> Al Brown/Costa Mesa/IBM@IBMUS
> <ecblank.gif>
> Cc:	<ecblank.gif>
> "Nikunj R. Mehta" <[e-mail]>, Atom-Syntax Syntax <[e-mail] 
> >, [e-mail]
> <ecblank.gif>
> Date:	<ecblank.gif>
> 06/08/2009 11:55 AM
> <ecblank.gif>
> Subject:	<ecblank.gif>
> Re: Fwd: New Version Notification for draft-divilly-atom-hierarchy-01
>
>
>
> Comments below...
>
> Al Brown wrote:
> >
> > The 01 draft is a much better. I am concerned the generic mechanism
> > using inlining links is sub-optimal for displaying a hierarchy that
> > this I-D helps navigate via the new link relations.
> >
> in-lining arbitrarily complex hierarchies is always going to be
> problematic and suboptimal... which is why I was so adamant about not
> baking hierarchy into Atom and Atompub in the first place when we were
> working on all this stuff initially.  Despite the added verbosity that
> this approach adds, however, I think it's likely the most acceptable
> approach.
>
> > First example: there are two down relations: down and down-tree.  
> It is
> > important to have both of those link relations on the [standalone]
> > atom entry that represents a folder so the client can chose a flat
> > (feed) or tree (expanded feed) representation. If the client chooses
> > the tree representation, then on the atom feed returned the server
> > will inline using the link relation down. down-tree is not expanded
> > with content inline. E.g.,
> >
> > <atom:entry>
> > ...
> > <!-- children level 1 -->
> > <atom:link rel="down" type="application/atom+xml;type=feed"
> > href="/finance/feeds/default/portfolios/1/positions">
> > <ae:inline>
> > <atom:feed>
> > <!-- /a -->
> > <atom:entry>
> > ...
> > <!-- children level 2 for /a -->
> > <atom:link rel="down"
> > href="/finance/feeds/default/portfolios/1/positions"/>
> > ...
> > <ae:inline>
> > <atom:feed>
> > <!-- entry /a/1 -->
> > <atom:entry>
> > ...
> > <atom:link rel="down"
> > href="/finance/feeds/default/portfolios/1/positions/down">
> > <!-- repeats -->
> > </atom:link>
> > <atom:link rel="down-tree"
> > href="/finance/feeds-tree/default/portfolios/1/positions/down" />
> >
> > ...
> > </atom:entry>
> > </atom:feed>
> > </ae:inline>
> > <atom:entry>...</atom:entry>
> > <atom:entry>...</atom:entry>
> > </atom:feed>
> > </ae:inline>
> > </atom:link>
> > <atom:link rel="down-tree" type="application/atom+xml;type=feed"
> > href="/finance/feeds-tree/default/portfolios/1/positions" />
> >
> > ...
> > </atom:entry>
> >
> > The contents of the down link relation will be what should be  
> included
> > in the down-tree due to recursion through the atom entries. Having a
> > separate extension element, side-steps this issue of expression.
> >
> Hmmm.... I know we've discussed this, but after thinking about it more
> and looking through the examples, I'm becoming increasingly less
> convinced that we need a distinction between "down" and "down-tree".
> One should simply assume that "down" could point to a child entry or
> child feed and that those children could potentially also be parents.
> Yes, that possibly increases the processing compexity but I think it
> simplifies the model overall.
>
> > Second example: verbosity
> > This proposal now has:
> > <atom:entry>
> > ...
> > <atom:link rel="down" type="application/atom+xml;type=feed"
> > href="/finance/feeds/default/portfolios/1/positions">
> > <ae:inline>
> > <atom:feed>
> > <atom:link rel="self"
> > href="/finance/feeds/default/portfolios/1/positions"/>
> > ...
> > <atom:entry>...</atom:entry>
> > <atom:entry>...</atom:entry>
> > <atom:entry>...</atom:entry>
> > </atom:feed>
> > </ae:inline>
> > </atom:link>
> > ...
> > </atom:entry>
> >
> > instead of a simpler mechanism:
> > <atom:entry>
> > ...
> > <ah:include rel="down">
> > <atom:entry>...</atom:entry>
> > <atom:entry>...</atom:entry>
> > <atom:entry>...</atom:entry>
> > </ah:include>
> > ...
> > </atom:entry>
> >
> > The I-D introduces a concept of hierarchy through
> > up/up-tree/down-tree/down relations yet a all-purpose mechanism for
> > inclusion. Most (all?) of the information on the feed element is
> > duplicated on the enclosing entry (id, uri, etc). Can't we do better
> > for this specific scenario the I-D is addressing?
> >
> I think we can address this by eliminating the restriction that "down"
> and "up" must always point to Atom feed documents and by changing the
> cardinality rules for those links. That restriction, I think, is
> arbitrary and unnecessary
>
> It would allow us to do something like....
>
> <atom:entry>
> ...
> <atom:link rel="down" type="application/atom+xml;type=entry"  
> href="child1">
> <ae:inline>
> <atom:entry>...</atom:entry>
> </ae:inline>
> </atom:link>
> <atom:link rel="down" type="application/atom+xml;type=entry"  
> href="child2">
> <ae:inline>
> <atom:entry>...</atom:entry>
> </ae:inline>
> </atom:link>
> ...
> <atom:link rel="down" type="application/atom+xml;type=entry"  
> href="childN">
> <ae:inline>
> <atom:entry>...</atom:entry>
> </ae:inline>
> </atom:link>
> ...
> </atom:entry>
>
> Unlike any of the other methods discussed, this approach would allow
> clients that don't understand the hierarchy model to still understand
> that there is some kind of link relationship with each of the  
> individual
> child resources and eliminates the need to include the extraneous
> atom:feed metadata.
>
> Note that this is the same basic approach taken by my comment thread
> extension (in-reply-to).
>
> - James
>
>
>