Hi Al, Apologies for responding to the feedback after a prolonged gap. An intervening holiday and vacation delayed this. Nevertheless, this is very useful feedback. Alternate links may be used in any and every Atom document. I am not sure what you are alluding to. For definitional purposes, the presence of an "up" link makes an entry a child entry and the presence of a "down" link makes an entry a parent entry. Any entry can choose to not include either or both of these links. This I-D disallows the use of multiple link elements with @rel="down", @rel="down-tree", @rel="up" and @rel="up-tree" directly within a single entry. There is precedent to specifying cardinality in link relations within Atom and I don't see a use case that will be disallowed by this I-D. I spotted the error in the illustration for child entry - it could state atom:entry instead of atom:feed. All the same, a feed can also use the "up" and "up-tree" relations just like a child entry. Section 2.2 Clarifying the containment model is also necessary for definitional purposes. Again, definitions are non-normative, unless explicitly stated using RFC2117 mechanisms. Does this cause any difficulties in reviewing or implementing the spec? Section 3 Both mechanisms, the one you suggest and the one in the hierarchy I-D, introduce the same kind of "burden" on processors - interpreting Atom markup inside Atom markup beyond what is described by the non-normative Atom RNG schema described in RFC 4287. The inline representation is a convenience mechanism where feed and entry documents can be housed within another Atom document. Servers have the option of specifying out-of-line content instead of using the inline representation. Therefore, it appears that the mechanism described in the I-D is better suited to the inline representation requirement. You are free to use the nested atom:entry inside atom:entry whenever the nested entry does not have any "self" or "edit" URI. Also, you are free to nest multiple atom:entry documents inside an atom:entry whenever there is no atom:feed that forms the same set of entries as the nested entries. However, this I-D does not address such a requirement because no relation is implied between the nested entry and contained entries. Specifying a relation is done using a link element, and that requires an href value. Doing what you suggest would require creation of two different mechanisms for the same thing modulo the server's ability to generate a URI. Would you mind describing why it would be not the right thing for a server to generate an href value, if it cares for the relation between entries? Nikunj On May 22, 2009, at 4:48 PM, Al Brown wrote:
|