Section 7.13 Hierarchical resources

[Anne Anderson <Anne.Anderson@Sun.COM>]

Attached is a substantial rewrite of Section 7.13 "Hierarchical
Resources" in light of our discussions and conclusions on WI#9
(policy predicates covering multiple nodes) and WI#42 (requests
for multiple nodes).

Here is a summary of the differences from the current version.

1. It makes clear the two main aspects of hierarchical resources:
   requests that ask for access to a hierarchical resource, and
   policies that protect a hierarchical resource.  It contains
   one sub-section for each of these aspects.

2. It requires ALL requests for access to a hierarchical
   resource, even if the request is for a single node, to supply
   the "resource-id", "scope" and "resource-content" Attributes.
   Supplying a "scope" Attribute is the way a request indicates
   that it is requesting a hierarchical resource.  It is valid to
   include a "resource-content" Attribute without a "scope"
   Attribute, but not vice versa.  The "resource-id" specifies
   either the individual node being requested, or the root of the
   sub-tree being requested.

   Requests for even a single node have to supply the
   "resource-content" because the policy may be expressed in
   terms of some ancestor or descendant of the requested node.
   Without a view of the full hierarchy, the PDP has no way of
   knowing whether the requested node falls into one of those
   categories.

3. There is no longer a default value for the "scope" Attribute.

   Unless there is an explicit value, the policy does not know
   that the resource-id refers to a node in a hierarchy.

4. If there is a "scope" Attribute, but no "resource-content"
   Attribute, then a single <Result> of
   <StatusCode>="processing-error" is mandated.

   This is because "scope" is now tied to the "resource-content"
   Attribute and has no meaning apart from it.

5. A default XML representation is supplied for hierarchical
   resources that are not themselves XML documents: the identity
   of each node in the hierarchical resource instance is the name
   of an element in the XML representation.

   I had rejected this approach (suggested by Michiharu earlier)
   because I thought it required a new schema to be defined for
   each instance of a hierarchical document.  I now believe this
   is not a problem.  XPath defines processing of XML documents
   for which there is no schema.

6. Nodes in hierarchical resources are identified using XPath 2.0
   expressions.

   Now that node identities correspond to XML element names,
   XPath expressions can be used effectively for all types of
   hierarchical resources.

7. If there is not a separate <Result> for each requested node,
   then each <Result> applies to its associated node and to all
   that node's descendants, except for those descendants having
   their own <Result> or a closer ancestor having a <Result>.  A
   <Result> of "Permit" means access to all the nodes to which
   the <Result> applies is permitted.  A <Result> of "Deny" means
   access to at least one node to which the <Result> applies is
   denied.

   This is part of an effort to supply clear semantics for
   hierarchical resource requests and responses.

8. I no longer try to provide functions for specifying ancestors
   of a given node, or for specifying attributes associated with
   ancestors.

   We just are not clear enough on how we should model the UFS
   "read/write requires execute on all ancestors" semantic.  This
   is the only use case so far.

9. There is one new DataType specified for use with hierarchical
   resources: http://www.w3.org/TR/xpath20.  Values with this
   data type refer to the node resulting from the specified XPath
   2.0 expression.

10. There are four new functions specified for use with
   hierarchical resources:

   a. xpath-node-match: matches two values of type
      "http://www.w3.org/TR/xpath20";, returning "True" only if the
      two values result in the same node in the
      "resource-content" hierarchy.
   b. "requested-nodes": returns a bag of
      "http://www.w3.org/TR/xpath20"; containing all requested
      nodes from the "resource-content" hierarchy.
   c. "xpath-node-and-descendants": returns a bag of
      "http://www.w3.org/TR/xpath20"; values corresponding to the
      node in its argument and all descendants of that node.
   d. "xpath-descendants": same as above except returns only
      descendants of the node specified in the argument.

   Using the higher-order bag functions, these functions allow
   matches against some or all requested nodes and/or against
   some or all nodes in a given sub-tree.

   Rationale: Once I realized that both the request and the
   policy might be specifying (different) subtrees in the
   "resource", I decided handling the subtrees as bags of values
   was simplest.  This may have been what Daniel was getting at -
   if so, my apologies for not understanding the value sooner.

11. COMMENT: If we do not supply functions that apply to all
    ancestors of a given node, then a "resource-content" needs to
    contain only the path to the node or nodes being requested
    and can stop there.  If we attempt to specify policies in
    terms of ancestors, then all descendants of the requested
    node or nodes must be included, since one of them might be
    the base of an ancestor path.

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

Section 7.13 Hierarchical resources