Nikunj R. Mehta wrote:
On Jun 8, 2009, at 11:56 AM, James M Snell wrote:
<snip>
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.
A client that does not understand anything about "down" or "up" will not
be able to do anything cogent with the linked resource other than say
that some kind of relationship exists. The ability to render the linked
resource is meaningless if the application is incapable of determining
the nature of the relationship. In such cases, the distinction of
having multiple rel=downs that point to alternate representations of the
same resource or that point to separate distinct resources is
meaningless and neither approach is more or less harmful or beneficial
than the other.
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.
This is backwards. Cardinality constraints are a restriction. To ensure
maximum flexibility, one needs to justify adding the restriction, not
justify removing it. All that I'm saying is that the existing
cardinality rules impose a restriction on the model that does not appear
to be strictly necessary and could potentially be harmful long term. For
instance, given the current definition, one would need to invent yet
another set of hierarchy rel relations in order to implement a graph
model, which, to me at least, seems counterproductive. Define "down" and
"up" more generically and move the cardinality constraints to the
application where they belong. Note that relaxing the cardinality does
not make it any more difficult to achieve the result you are looking
for. An application could still use multiple rel=down links to point to
alternate language representations of the same logical child feed, for
instance, Atom processors would simply treat those alternate language
representations as separate child feeds leaving it up to the application
to make the appropriate connections.
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.
I would be interested in learning about the implementation experiences
for this as well. I purposefully left that model to be as flexible as
possible, with as few constraints as possibly, specifically in order to
avoid placing arbitrary and premature restrictions on implementations.
If implementation experience shows that specific restrictions would be
helpful, then I would be more than happy to work on a BCP describing
those restrictions.
- James
