On Jun 8, 2009, at 11:34 AM, James M Snell wrote:
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...
Good to have you back in active participation on this list.
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?
The cardinality model is defined in Section 4. Section 2 only
introduces the meanings of certain relation type and a model for
relating entries and feeds.
The I-D could have claridfied that a multi-parent relation is
expressed through @type="application/atom+xml;type=feed" in
combination with @rel=up.
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">.
Wouldn't this merely repeat information from the atom:link element?
Why is it a better model? What happens if the atom:link @type and
ae:inline @type differ from each other?
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]".
Of course, the full processing model can be specified in the I-D, but
we intentionally referred to the atom:content processing model as the
archetype. If the best way to specify this behavior is to repeat the
text in hierarchy I-D, that can be easily done.
Section 4
<snip>
We are separately discussing this topic, so omitting here
Section 5.3: There is a bug in the example. The </ae:inline> and </
atom:feed> closing tags have been transposed.
Noted. Thanks!
