Based on this situation, my proposal is to enhance the existing Hierarchical spec using the URI representation in section 3.2 and indicating that this approach can be used instead of resource-parent and ancestor when the hierarchies are represented by nodes with URI resource-ids.
Using URI is a very limited approach, and it can be trivially mapped into "ancestor" approach. Requiring a unique URI for resources is often not feasible
The following example will show why this is doubly and actually triply specified and also why it is essential that the changes described in 1-3 above are needed.
Consider 3 hierarchies:
/a1/b1/c1
/a2/b2/c2
/a3/b3/c3
Let's say that a1, a2, and a3 are distinct roots and represent 3 separate nodes (or resources) in the overall collection.
I think you are confusing physical resources and policy resources. Such mapping is outside of XACML. There is no real hierarchy in XACML, we just provide a convenient normative way to represent them - only for the purpose of using it in a policy target.
For the purpose of a single policy evaluation hierarchy that is used is uniquely defined by the provided "resource-ancestors" attribute. The fact that there is some persistent identity that may participate in different hierarchies should be outside of the scope of this profile.
Daniel;
