A question I have is how many folks are really using this hierarchical
profile in practice.
Daniel Engovatov wrote:
>
> On Jan 14, 2009, at 10:54 PM, Rich.Levinson wrote:
>
>> * There needs to be a definition of "hierarchy". In particular, a
>> "hierarchy" defn should state that the fundamental properties are
>> that there must be a single root node with no parent, and that
>> every other node in the hierarchy must have one and only one
>> parent, and can have zero, one, or more children.
>
> I am not sure why do you think this is a requirement. It is a normal
> use case to inherit policy from more then one parent, and "ancestors"
> attribute approach allows such models without undue restrictions.
>
>> in order to submit a request one has to somehow identify all the
>> hierarchies the given node
>> belongs to, all the hierarchies the node's parent(s) and
>> ancestors to, and include an Attribute element for each.
>
> And why is that a problem? Yes, if one wants "inheritance", graph
> needs to be defined, and attributes is a natural way to define it.
>
>> I suspect that at most one would need to collect all the normative
>> representations of only the resource-id node (i.e. identify all the
>> hierarchies it belongs to), then for each hierarchy, one would
>> evaluate the policies that apply to that hierarchy.
>>
>
> Policy evaluation does not need to know anything about hierarchies
> that are represented with an "ancestor" attribute.
>
> Daniel;
