Comments on hierarchy draft

[James M Snell]

Great to see a bunch of activity on the list... I'm finally starting to 
find time to catch up on what's been going on. The hierarchy draft looks 
good at first read but I had a few comments and concerns...

Forgive me if any of this has already been discussed, there have been a 
significant number of posts on the hierarchy draft and I simply have not 
yet had time to dig through them all.

Section 2.1

The cardinality model really isn't all that clear to me upon first read 
of this draft so please bear with me. The draft would seem to indicate 
that any given entry can have multiple parent entries. Does this mean 
that the entry can have multiple "up" links, each pointing to a 
different parent Atom entry document, or a single "up" link pointing to 
a single Atom feed document containing all of the parent entries?

Section 3.2 If the ae:inline element is supposed to allow arbitrary 
content then it is underspecified. For instance, the atom:content 
element contains a specific type attribute used to indicate whether the 
content is text, html, xhtml or some specific media type. If the 
media-type is binary based, atom:content requires that the contained 
data be Base64 encoded.  If the media-type is text based, atom:content 
requires that the characters be included as inline-text. If the 
media-type is xml based, atom:content requires that the xml be in-lined 
directly. I know the specification indicates that the optional type 
attribute of the enclosing atom:link element is intended to provide the 
necessary information, I think it would make far more sense for the 
ae:inline element to have it's own type attribute modeled after the 
atom:content type attribute. e.g. <ae:inline type="text">, <ae:inline 
type="application/atom+xml;type=entry">.

It would also make sense to explicitly spell out the processing model as 
is done in RFC 4287 for atom:content rather than just saying "process 
the value of ae:inline per the processing model for atom:content as 
specified in Section 4.1.3.3 of [RFC4287]".

Section 4

I'm not sure I'm comfortable with all the restrictions placed on the 
hierarchy model. "up" and "down" links should be able to point to 
individual Atom entry documents as well as feeds, for instance... it 
would make sense to be able to do something like...

<entry>
  ...
  <link rel="down" type="application/atom+xml;type=entry" 
href="childentry1.xml" />
  <link rel="down" type="application/atom+xml;type=entry" 
href="childentry2.xml" />
  <link rel="down" type="application/atom+xml;type=entry" 
href="childentry3.xml" />
  ...
  <link rel="up" type="application/atom+xml;type=entry" 
href="parententry1.xml" />
  <link rel="up" type="application/atom+xml;type=entry" 
href="parententry2.xml" />
  <link rel="up" type="application/atom+xml;type=entry" 
href="parententry3.xml" />
  ...
</entry>

This would imply also that each "down" and each "up" link point to 
distinct resources as opposed to alternate representations of the same 
resource... in other words, it expands the hierarchy model out to allow 
any single element to potentially have multiple child trees and multiple 
parent trees.

<entry>
  ...
  <link rel="down" type="application/atom+xml;type=feed" 
href="childfeed1.xml" />
  <link rel="down" type="application/atom+xml;type=feed" 
href="childfeed2.xml" />
  ...
  <link rel="up" type="application/atom+xml;type=feed" 
href="parentfeed1.xml" />
  <link rel="up" type="application/atom+xml;type=feed" 
href="parentfeed2.xml" />
  ...
</entry>

Yes, this increases the potential complexity of the hierarchy model, but 
restricting the model to only a single child tree and single parent tree 
feels like needless premature optimization.

I think the difference between "down" and "down-tree" and "up" and 
"up-tree" needs to be spelled out with more clarity.

Section 5.3: There is a bug in the example. The </ae:inline> and 
</atom:feed> closing tags have been transposed.

- James