[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Section 7.13 Hierarchical resources
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]