OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Issue: Severe Error of omission in description of Hierarchal Profileancestor collection algorithms


This issue is intended to officially replace an existing issue, as will be described below. In addition to pointing to the background emails (item 1, below), a fresh explanation of the user visible characteristics of the issue that is being raised will be described below (item 2 below).
(Note: to people who have followed this issue, there should be nothing new in this issue except to present it in terms that should make determining its disposition should be easier for all to understand.)
Finally, the slightly modified recommendation referenced below is included as item 3 below:

Item 1. Background reference points for this issue (one does not now have to follow these links and may skip to #2 below, but they are here for anyone who wants or needs additional context):

the issue that initiated two clusters of long email discussions in the past several weeks, with the first cluster initiated by this email:

the 2nd cluster was initiated by this email:

a commenter was also using the profile and requesting advice, which has also contributed to demonstrating exactly why the omission in description is considered to be severe, although, exactly what the commenter was expecting has not yet been determined precisely:

Finally, an initial proposal was suggested in this email, and is effectively what will be proposed here, except it will take into consideration the comments of the reply to that email:

Item 2. "User-friendly" description of the issue:

The launching point for understanding this problem may be seen in version 2.0 of the hierarchical profile, all of which has been carried over to version 3. The following paragraph on lines 73-77 of the Hierarchical Resource Profile is where the problem begins, which is carried thru the rest of the spec:

  • "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”."
The problem with this paragraph is that it equates 2 structures: Forest and DAG. While it is true that a Forest is a subclass of DAG, the behavior of these two objects, just as subclass and superclass in object-oriented programming, is quite different.

Both these objects define an "ancestor" collecting algorithm, such that when one identifies a node that access is requested to (the requested node), the algorithm of the Forest and DAG specifies what "ancestors" of the requested node to collect in order to determine what nodes contain the requested node within their "scope".

By scope, what is meant, is that in hierarchical resources one often defines the scope of a policy to be a specific node and all the nodes in the subtree below that node. It is both the contents of the subtrees of nodes and the set of ancestor nodes that is different between the Forest and the DAG, as will now be explained.

This conceptualization is intended to show the distinctions between a Forest and a DAG. This first set of bullets is intended to describe the meaning of a DAG in terms of the hierarchies involved and what happens to them as the concerning their "multi-hierarchical" properties:
  • For a single hierarchy, the DAG and Forest are equivalent.
  • It is only when you get cross-cutting and overlapping hierarchies that the differences begin to appear, and the difference is that with DAG, when you lay down the 2nd hierarchy you sweep up not only the exact overlapping nodes of the first hierarchy, but the subtrees of all those nodes as well. So, you get a "hierarchy plus". The "plus" is still a hierarchical part of the 2nd hierarchy, but it is "additional" stuff that is not in the original 2nd hierarchy.
  • There is also a "plus" on the first hierarchy as well. Specifically, when you lay the second hierarchy on the first, every node of the first hierarchy which is a new member of the 2nd hierarchy, also picks up additional members of the 2nd hierarchy that are in the subtree of the node from the 2nd hierarchy that is overlapping the node of the 1st hierarchy.
By contrast, for a Forest, which has a generally accepted definition as to be a "disjoint set of trees":
  • When you lay down the 2nd hierarchy over the first, any node of the 1st hierarchy becomes also a node of the 2nd hierarchy, any node in the 1st hierarchy that is not overlapped explicitly by the 2nd hierarchy is not a member of the 2nd hierarchy.
  • Similarly, the 2nd hierarchy only picks up the nodes of the first hierarchy that actually overlap. i.e. the number of nodes in the 2nd hierarchy does not change. The only change is that some nodes in the 2nd hierarchy are now members of the first as well. Similarly, the first hierarchy is also unchanged in members, except that some of its members are now also members of the 2nd hierarchy as well.
Hopefully, the description above should make it clear that Forest and DAG are quite different objects, and that it is important to identify them as such in the Hierarchical Resource Profile. Currently, the only description of ancestor collection given in the profile is that for the DAG in section 3.2 of the profile.

Interestingly, the URI naming issue is incidental and not a core factor in resolution to this issue, because its only significance is that it is very handy and has great performance advantages when used with the Forest model, however, it is not particularly useful with the DAG model, because the hierarchy it represents is only a portion of the "hierarchy" that is "available" with the DAG.

Item 3: Proposed resolution for this issue:

The recommended solution to address this problem is the following, which as mentioned above is a slight modification in the ref'd email above:
  1. Modify existing document so that nonXML nodes are described with DAG option and with Forest option. This can be done minimally as follows:
    • Add explanatory text, similar to what is above in section 1, intro text and glossary to explain distinction of Forest and DAG.

    • Optionally add a new identifier in section 2.2 to indicate that that use of URIs are inherently forest-oriented (keep existing definition for compatibilty but both mean exact same thing):
      • "urn:oasis:names:tc:xacml:2.0:profile:hierarchical:forest:non-xml-node-id"

    • Add an identifier in section 3.2 to indicate the forest algorithms:
      • "urn:oasis:names:tc:xacml:2.0:profile:hierarchical:forest:non-xml-node-req"

    • Add an alternative set of bulleted algorithms to section 3.2, which are the same as the existing ancestor algorithms except specify that only the parent and ancestor nodes of the requested node are collected which are direct ancestors of one of the normative identities of the requested node (which is possible, because with a forest the original parent identifier is always retained for each hierarchy the requested node still belongs to or has been added to since joining the forest)

  2. Other options include any variation, rearrangement, separation, or enhancement of the existing profile that builds on and includes the contents identified in #1.
The above is intended to be a minimally intrusive change to the existing spec that does not alter any existing functionality and simply explains the distinction between Forest and DAG and provides information on the manner in which the Forest ancestor collection algorithms operate, which was already implicit (but not explained in any way) by simply using URIs with the anyURI-regexp-match function for scoping.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]