Issue: Hierarchical profile appears ambiguous and inconsistent

["Rich.Levinson" <rich.levinson@oracle.com>]

I am finding the Hierarchical profile ambiguous and inconsistent and 
therefore incomprehensible, which may, similarly to the Multi-Resource 
profile be because there are essential contextual paradigms missing from 
the specification.

For the Multi-Resource profile, the missing contextual paradigms included:

    * It is necessary to pre-process the multi-resource request and
      submit individual requests to the PDP, and then to package up the
      responses into a single response.
    * The PDP, itself, can only process Request elements that in 2.0
      contain a single Resource element, single Action element, single
      Environment element, and multiple Subject elements, but each
      Subject element has to have a distinct SubjectCategory attribute,
      and in 3.0 there can be multiple Attributes elements, but each has
      to have a distinct Category attribute.

Once the above paradigms are established, the Multi-Resource profiles 
become comprehensible.

I suspect something similar is going on w the Hierarchical profile also.

Here is the background on the Hierarchical profile that I am trying to 
work thru (each bullet represents a potential issue to resolve or 
suggestion for improvement):

    * 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.
    * Section 3.2 is the biggest problem. To begin, the following needs
      confirmation: it appears that the key structural sentence for 3.2
      that explains what the four bullets that follow it are is lines
      314-315 (which is sandwiched between a negative statement on
      ResourceContent and subsequent 3 sentence "note") that state:
          o "The request context <Resource> element SHALL contain the
            following elements and XML attributes."
    * Each of the 4 bullets in section 3.2 contains the phrase "(for
      each) normative representation (of some node ...)". I think this
      is the core of the problem I am having understanding this spec.
      What I think it means is that for a given collection of physical
      resources, such as files in a file system, that in additional to
      the conventional file identification by directory path, which
      includes all the files in the file system, that other logical
      hierarchies that can span part or all of this set of resources
      also needs to be taken into account. And that the "normative
      identity" of a specific "file" is within the context of a specific
      hierarchy. i.e. each hierarchy that covers all or part of this set
      of resources has its own "namespace" and within that namespace has
      a scheme for hierarchically naming its members. As such, a given
      physical resource can belong to any number of these hierarchies
      simultaneously, and has one "normative representation" for each
      hierarchy it belongs to. And presumably, the point is that each
      hierarchy the resource belongs to may have its own restrictions to
      apply to resource, so we have to identify all of them to get the
      full picture.
    * Given the above characterization of the multiple "hierarchies" a
      given resource can belong to, it then appears that the four
      bullets in section 3.2 state that 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.
    * There appears to be some over-specification above and beyond what
      is presumably intended (assuming the above characterizes what is
      "presumably intended"). For example, since a node in a hierarchy
      can have only one parent, and if a node belongs to multiple
      hierarchies, then that node will have one and only one parent for
      each hierarchy it belongs to, the following sentence (lines
      324-325) appears to doubly state this relationship:
          o "For each immediate parent of the node specified in the
            “resource-id” attribute or attributes, and for each
            normative representation of that parent node ..."
            i.e. the node specified in the resource-id can only have one
            parent wrt the the node's normative representation with a
            specific hierarchy. There seems to be no point to looking at
            a parent node in any other context than the normative
            context of the resource-id node. i.e. if a node only belongs
            to one hierarchy, but its parent belongs to many, then the
            other hierarchies the parent belongs to should have no
            impact on the child since the child is not a member of those
            hierarchies.

Assuming the above characterization is even close to correct, I am still 
wondering "why" all this information is being assembled and what the 
Policy is expected to do with it. i.e. what is the policy evaluation 
paradigm that is being represented here? 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.

Thanks,
Rich