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

[James M Snell <[e-mail]>]

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