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

[Al Brown <[e-mail]>]

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).  Both are the same document just with or without inlining
of linked resources of a particular link relation.  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.
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.
c. leverage link templates rather than link relations
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.


                                                                                                                                
  From:       James M Snell <[e-mail]>                                                                                 
                                                                                                                                
  To:         Al Brown/Costa Mesa/IBM@IBMUS                                                                                     
                                                                                                                                
  Cc:         "Nikunj R. Mehta" <[e-mail]>, Atom-Syntax Syntax <[e-mail]>,                            
              [e-mail]                                                                                    
                                                                                                                                
  Date:       06/08/2009 11:55 AM                                                                                               
                                                                                                                                
  Subject:    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