Hi Daniel and TC,
Hopefully, those who have followed the details of these emails
recognize that each step in the sequence has advanced the discussion in
a consistent manner and as a result we have done a fairly thorough job
of mapping out the problem space that is under discussion. In any event
I believe my comments in this email continue to advance the discussion
in a worthwhile manner, and I think will describe the complete problem
space as well as give a clear description of the options available, all
of which offer full functionality.
In the current phase, if I am not mistaken, it is a straight-forward
matter to apply definitions to the distinct categories of problems and
simply observe that we have two sets of tools which are equally
effective at solving each category of problem, where
- one set of tools (let's call it the "ancestor method") is most
effective when one is dealing with resources where it is not possible
or desirable to apply URIs as normative identifiers
- a second set of tools (let's call it the "URI method") which is
available when one is dealing with resources where URIs can be applied
as normative identifiers, and the designers want to take advantage of
the powerful features inherent in URI objects, esp when applied to
hierarchical problems.
Let me address Daniel's points below, then try to summarize the present
state of the discussion:
Daniel Engovatov wrote:
On Feb 18, 2009, at 3:05 PM, Rich.Levinson wrote:
Daniel, Seth, Erik, and TC,
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
It is NOT a generally accepted definition and we did not stick to it on
purpose.
Whether it is generally accepted or not is probably not important here,
however, it is consistent with the structure of XML documents, such
that when we are talking about a "single hierarchy" of nonXML resources
that if we assert that this implies a structural relationship
equivalent to the structural relationship of the nodes of a well-formed
XML document, which is that each element can have at most one parent,
and the top element or node has zero parents.
This gives us a crisp unambiguous definition of the term "hierarchy"
which can be applied both to the XML and nonXML resources, and it
totally avoids trying to determine whether it is an "accepted"
definition or not, since that property is no longer relevant.
The point of this definition is to give us a conceptual framework
within which to evaluate the two primary use cases of the DAG, which as
will be explained are also clear and unambiguous well-defined use cases.
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.
It is NOT "broken down"
True, in an absolute sense nothing is "broken", however, what has
happened is that we have allowed one class of DAG representation to be
impacted in such a way that we have allowed it to become the second
class of DAG representation because we did not clearly define the
distinction and what was to be allowed and not allowed. This has
nothing to with whether the ancestor or URI method is used. It has only
to do with the relationships that are allowed to be represented when
two resources are "connected" by virtue of their hierarchical
relationship being established.
Specifically, one has a choice of:
- only allowing the relationship that is being established to be
active. For example if my boss is assigned to be subordinate to a task
force leader when a cross functional team is being set up, this case
would say that has no impact on my relationship with the task force
leader unless I am a member of the task force. i.e. the task force
leader has control over my boss's resources to whatever degree is
implied by the task force situation, however the task force leader has
zero direct control over my resources as a result of this assignment.
In this model, that direct control could be simply be established by
either assigning me directly to the task force leader, or assigning me
a second subordinate relationship to my boss in the context of the task
force relationship.
This is a clearly defined process, where there is no ambiguity about
relationships between the resources. If you want the relationship, you
explicitly establish it, if not, you don't.
- the other choice is the exact opposite, namely allowing
incidental relationships to be established simply because they connect
to a node with direct relationships. To take an extreme light-spirited
example, for the purpose of showing how "extraneous" relations are
introduced, if the company CEO was a member of a company bowling team,
where the captain of the bowling team happened to be a junior software
engineer who just joined the company, then everyone in the company
would suddenly have this junior engineer as their ancestor. Possibly
this would be disallowed by acyclic graph rules, but a similar
situation would occur if the VP of engineering was on a bowling team
captained by the junior sales trainee, who would now be ancestor to
everyone in engineering organization.
Both methods are acceptable for assigning relationships, but one or the
other may be more effective for one or another type of organization.
Personally, I think most enterprise security departments would favor
the first approach, because it appears to offer more direct control and
less chance of unintended consequences resulting from the assignment of
a direct relationship.
However, either choice can be used with either the "ancestor method" or
the "URI method". Which choice is made is a function of the node
collecting algorithm that is used for policy evaluation. i.e. when you
collect the parent nodes of the requested node,
- choice 1 above means only collect those nodes to which the parent
has a direct relationship with the requested node,
- and choice 2 means collect all the nodes of choice 1 plus all
other nodes where the parent has a hierarchical relationship that does
not directly involve the requested node.
These are the two primary use cases of the DAG, which were mentioned
above. Which use case is chosen depends only on the node collection
algorithm and not how the nodes are represented. i.e. parents and
ancestors exist whether or not they are incorporated for handy access
within a URI or not.
When the URI can be used, the URI collection within the requested node
itself contains all the nodes that will be collected with method 1 and
there is no need to access any additional information.
Again, I am not trying to add or change any
of the existing functionality,
You are proposing an addition that is a subset of the more general
approach.
Hopefully, the description above satisfactorily demonstrates that the
URIs are simply a concrete mechanism to implement the general solution.
It is also a mechanism that, if used effectively, appears to be much
more efficient since all nodes that need to be collected in method 1
actually are already contained in the URI collection of the requested
node.
Therefore it is a concrete representation of the general approach,
however it is a concrete representation that capitalizes on the fact
that the object used to represent the node (the URI) has an equivalent
structure to the spatial relationships of the nodes in the DAG that
need to be collected in method 1, and so those nodes do not need to
collected at all since they are already present.
The same structural relationship exists in method 2, however, method 2
fans out so far so fast that collection outside the requested node will
be required to fulfill the needs of method 2.
It is functionally equivalent to the general approach, however, it has
the advantage that a single URI contains the normative identity of all
the required nodes for method 1 and some for method 2.
I understand that you favor a different approach to this problem. It
may be worth our while to create a separate profile for such an
approach, but I do not see any reason to muddy the existing one.
It should be clear from the above discussion that showing how URIs
address the same problem is not a "different approach". It is the same
approach, except the work required to collect the nodes is a lot less,
and can be eliminated almost completely depending on what node
collection strategy is chosen, method 1 or method 2.
Finally, it should be clear that the bulleted algorithms in section 3.2
of the spec represent a nonURI approach using a method 2 collection
algorithm.
Now that the problem is clearly defined, I expect it will take much
fewer words than have been exchanged in these emails to explain the
available options in section 3.2, which are:
- method 1 node collection, URI method (all nodes required are in
requested node)
- method 1 node collection, ancestor method: (requested node has
pointers to parents, but need to recursively navigate to parent to
advance up the hierarchy, but does not navigate thru nodes of which the
requested node is not a hierarchy member)
- method 2 node collection, URI method (subset of nodes required
are in requested node, the rest must be obtained by recursively
navigating based on parent hierarchy nodes of which requested node is
not a member)
- method 2 node collection, ancestor method (this is the algorithm
currently in section 3.2 bullets and need to recursively navigate thru
all parent nodes regardless of whether requested node is a member of
the hierarchy or not.)
These 2 choices of node collection are implicit in the DAG problem
definition and are not currently explained in the document and I
believe need to be. i.e. a DAG is the result of a set of hierarchies
(as defined above) being layed across a set of resources. i.e. it is
the result of a set of explicit relations being applied between pairs
of nodes. The "choice" is whether to retain the "history" of why those
relations were applied (i.e. the direct relations) or not. If you don't
then additional, indirect, extraneous relations automatically appear
and there is no way distinguish between them and the direct relations,
at least in the "general" or "ancestor" case. In the URI case, the
direct and indirect relations are always present and may be used or not
as a matter of choice.
The choice of ancestor or URI method for node identification is simply
whether URI "can" be used and whether URI is "desired" to be used.
Functionally, URI will produce the same results.
Thanks,
Rich
Daniel;
|