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:
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;
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
