On Feb 19, 2009, at 8:03 PM, Rich.Levinson wrote:
> Hi Erik,
>
> A few points I'd like you to consider with respect to your first
> point:
> I am not sure why you have chosen to refer the URI scheme as the
> "limited URI scheme", because as I showed in previous emails, it
> appears that the URI scheme is, in fact, more general than what you
> refer to as the "more general approach advocated by Daniel". The
> reasons for this are quite simple. First, the URI scheme is
> functionally equivalent and more efficient as can be easily seen as
> follows:
I do not think you have shown it.
>
> in the ancestor scheme, as I understand it, we might have a node,
> "a", which is a normative identity for a particular node, and it
> might have 2 ancestors, a parent, "b", and ancestor "c".
> Presumably, if a request to access "a" comes in, the CH will have
> to gather the ancestors. This means the CH must have some means of
> finding out that "b" and "c" are the ancestors of "a". Since this
> information is not included in the node name of "a", the CH must
> look elsewhere.
You do not need to gather ancestors. They are included in the
attribute. You need to gather applicable rules. Rules have a
specified target.
> in the URI scheme, I would name my "a" node as "/c/b/a" using the
> same strings as above. In the URI scheme, a request for "a" would
> come in as "/c/b/a". In this case, the CH is done, it doesn't have
> to go looking for ancestors for 2 reasons: 1. because it doesn't
> need them, 2. even if it did need them, they are already there.
I do not understand what "looking up ancestor" you are talking
about. One need to look up rules.
>
>
> The reason why the URI scheme is more general is a bit subtle, but
> still should be straight-forward to understand. The subtlety is
> that when presented from an inverted perspective, it might at first
> appear that the ancestor scheme is more general, but a few quick
> points should explain why that is not the case:
> Sticking with the same use case as above as a starting point, let
> us consider the case where "b" has 2 parent nodes "c" and "d". I
> don't believe there are many people who would argue that this
> structure is still a hierarchy, however a rational case could be
> made that it is actually 2 hierarchies, one headed by "c" and one
> headed by "d". In this case "b" would be a member of 2 hierarchies.
I do not see anything "rational" in this case, and I do not see any
reason why it could be made. The rest of the argument is based on
this flawed straw-men assumption.
Daniel;
