[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent
Daniel, Seth, Erik, and TC,|
As should be seen from my replies in line, it appears to me the fundamental point of disagreement here is about the definition of the term "hierarchy". If we stick to the generally accepted definition that an object in a hierarchy can have at most one parent, then a URI solves the problem without having to look beyond the URI itself (a rather remarkable and powerful property). If we define a forest to be a collection of hierarchies, where, like in a forest, even though the members are intertwined, they do not lose their identity, then each node having a set of URIs as its normative identifiers solves the problem, as all the parents, ancestors, are self-contained in the set of URIs.
However, if we allow the hierarchies to break down and lose their inherent hierarchical properties, then more complicated approaches, such as going outside the initial request context to get more nodes, although still solvable w URIs as demo'd below, are needed.
Again, I am not trying to add or change any of the existing functionality, which, as described below is currently designed to address the "more complicated than hierarchies" problem. I think one of the main problems with the spec is that it leads you to think you are addressing a problem related to hierarchies, yet the solution described is much more general than that, which, imo, is misleading, unless it is appropriately documented as such. And if the resources under consideration are not identified by hierarchical names then the approach currently in the spec, qualified by whether it is strict hierarchies or hierarchies obscured by non-hierarchical relations that are incidentally introduced when using multiple hierarchies and not keeping track of the origin of each hierarchy.
However, I do want to show by example how the strictly defined hierarchy and forest of hierarchies, that each retain their initial hierarchy properties, is addressed using URIs along the lines of the example document that is in the archives and referenced below.
Rich (additional replies inline below)
Daniel Engovatov wrote:
This may be at the core of this issue. In a hierarchy, an node can have at most one parent. A node can belong to more than one hierarchy, in which case it has one parent for each hierarchy it belongs to. As soon as we start defining structures where the normative identity of a node can have more than one parent directly related to it, we are no longer talking about hierarchies, but some other more general structure. However, this is the "Hierarchical Resource Profile", where the subject is to
But this is not a "generic profile" it is the "Hierarchical profile".
It is simply a concrete real world realization of the notion of hierarchy used for illustrative purposes to give people context to help them understand the nature of the problem that is being addressed.
However, it does the job in a much more difficult to understand manner, which is probably because it is a mechanism that appears to be intended more complex problems than hierarchies.
I agree. That is an overstatement. I should have said "so obscure as to be unusable in the normal manner one would expect to use URIs", which is shown in the example document that was part of the process of developing this specification:
Again, I have to repeat that I am not "introducing" the URI scheme. It is already there in sections 2.2, 4.1, 4.3 with explicit descriptions of how it can be used. What's missing is an operational description of how it can be used in section 3.2.
Furthermore, it does not reduce any functionality related to hierarchies, but I agree that in its most basic form it would not solve the more general non-hierarchical problem. However, as explained in previous email, that is easily corrected, by "going out" and getting the non-hierarchical guests that are collected in its ancestors. In its basic form, intended to address the pure problem of a forest of multiple hierarchies, it does not need to "go out" for anything, because all the required information is contained in the normative identities of the requested node.