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;
