On Jun 8, 2009, at 11:56 AM, James M Snell wrote:
<snip>
Al Brown wrote:
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.
I don't find this argument quite convincing. For starters, if a client
doesn't understand rel="down" it will make no difference whether there
are multiple of those or a single one. Secondly, a client that does
the most generic thing possible can at least "render" a feed provided
in @rel=down in a cogent way. A feed that has rel=down scattered all
over the place will be more harmful than beneficial.
I can see how there is value in sporting a more flexible (and hence a
more complex) model, I fail to see requirements for adding this
complexity. Rather than treating the hierarchy I-D approach as
arbitrary, I implore the group to identify reasons to expand the
cardinality before making this arbitrary choice.
Note that this is the same basic approach taken by my comment thread
extension (in-reply-to).
The whole processing model for multiple occurrences of @rel="replies"
is underwhelming. From RFC 4685, Section 4,
Multiple replies links appearing within an atom:entry may reference
alternative representations of the same set of responses or may
reference entirely distinct resources containing distinct sets of
responses. Processors MUST NOT assume that multiple replies links are
referencing different representations of the same resource and MUST
process each replies link independently of any others.
I would be interested in learning about the usage experience with
multiple links for replies, especially in consumers of documents using
replies links with multiple occurrences.
