Hi Daniel,

Thanks for the feedback. Let me try to clarify a bit. My first objective is to understand what the spec currently says, and I am finding that the terminology is inherently ambiguous, and as a result, to me at least, that makes the details of the spec impossible to understand. So, what I did was try to disambiguate by defining "hierarchy". Let me be more explicit:

Lines 73-77 state the following:

In this Profile, a resource organized as a hierarchy may be a "tree" (a hierarchy with a single root) or a "forest" (a hierarchy with multiple roots), but the hierarchy may not have cycles. Another term for these two types of hierarchy is "Directed Acyclic Graph" or "DAG". All such resources are called hierarchical resources in this Profile. An XML document is always structured as a "tree". Other types of hierarchical resources, such as files in a file system that supports links, may be structured as "forests".

This is an inherently self-contradictory definition. A hierarchy has a single root. It is an "ordered set", where each entity in the set has a defined relationship to every other entity. A "forest" is not a hierarchy. It is multiple hierarchies. The "definition" above is not meaningful because it equates the singular and plural.

As a result of this self-contradiction, the spec then goes to introduce what, to me are meaningless concepts, such as lines 315-316:

Note that a node in a hierarchical resource that is not represented as an XML document MAY have multiple parents.

Therefore, in order to understand what the spec says, I first found it necessary to come up with an unambiguous term for "hierarchy", which allows sentences such as the above to be restated in a "meaningful" way, such as:

Note that a node in a hierarchical resource that is not represented as an XML document MAY *belong to multiple hierarchies and have a parent associated with each one*.

I am not saying anything so far is "wrong", simply that it is not understandable without firming up the definitions.

wrt to the "somehow identify all the hierarchies a node belongs to" comment, I was not saying it was a problem, but simply observing that that was what the spec was saying in terms of specific defn of the term "hierarchy".

Finally, I do not understand your comment that says:

Policy evaluation does not need to know anything about hierarchies that are represented with an "ancestor" attribute.

I am trying to understand what policies are supposed to do with the definitions in the spec. i.e. it is the spec that says in section 3.2 that all the parent and ancestor nodes need to be assembled in the request context. What "policy evaluation" are you referring to? Are you saying what I indicated in original email that a policy does not need to know anything about hierarchies that the resource-id node does not belong to?

Thanks, Rich

Daniel Engovatov wrote: