On Mon, Jun 8, 2009 at 3:30 PM, James M Snell<[email protected]> wrote: > > > Nikunj R. Mehta wrote: >> [snip] >> >> 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.
I am definitely in agreement w/ James here. I'd like/need to be able to have multiple 'up' and 'down' links of the same type and let the application sort 'em out. 0:1 is a constraint I'd need to figure a way around. --peter >>> >>> >>> Note that this is the same basic approach taken by my comment thread >>> extension (in-reply-to).
