Hi Daniel,
I am not sure exactly what you are driving at here, but I include
comments below:
Daniel Engovatov wrote:
For example, all the PCs in a company have
serial numbers. When managers create policies, they have the physical
resources in mind and may organize them hierarchically for various
purposes. A department manager may label the PCs in his/her dept
according to some hierarchical structure in the dept organization and
assign policies accordingly. At the same time these PCs are company
property and may be labeled independently by the IT dept in terms of
who is responsible for maintenance on them.
If someone wants to take one of these PCs out of the building, maybe
there is a policy that says even if the employee's manager says it is
ok, the facilities manager must also approve before permission is
granted. This can be modeled with a dept hierarchy and a facilities
hierarchy, and there are rules within the hierarchy producing a result
and policy combining between the 2 hierarchies that can resolve
conflicts such as described above.
In the above example the /a1/b1/c1 might be the dept hierarchy and
/a2/b2/c2 might be the facilities hierarchy.
There is no need for separate hierarchies here if the "remove from
building" is a single access decision. In your example, let's "PC" be
a resource, "DEPT" be a department, and "FACILITIES" be facilities.
In this case resource-ancestors will be {"PC", "DEPT", "FACILITIES"}
(or {"a1", "a2", "b1", "b2", "c"} ) There is no need for two
hierarchies. That is the advantage of not being pidgeonholed into a
single inheritance URI-like scheme.
The hypothetical scenario I am describing is based on two
sub-organizations within a larger organization which operate
independently on the same set of physical resources. In general, the
operations are independent, but in some cases there is need for both
organizations to be brought into some kinds of decision. The dept
manager has set up a hierarchy for controlling the PCs in his
department, while the facilities manager has set up an independent
hierarchy on the same set of PCs for controlling the maintenance on
those PCs from within the facilities organization.
The parent organization recognizes that there may be situations where
the decisions of the two organizations may come into conflict and have
set up combining algorithms above the two hierarchies to resolve
differences.
From what you are saying, and I do not follow your example, it sounds
like it is possible to restructure the existing hierarchies into a new
framework where somehow the existing hierarchies no longer need to
exist. This may be useful as an academic exercise, but operationally,
one would need to educate the company, the facilities and the
department about this new uniform paradigm and explain to the people
involved why they no longer need the hierarchical representations.
However, I do not understand precisely what you are recommending:
I do not understand how {"PC", "DEPT", "FACILITIES"} relates to
the scenario I have described. I have specific PCs, in the example they
have serial numbers r5, r6. One of these PCs, r5, is identified in the
"dept" as /a1/b1/c1. In the facilities org the same pc is identified as
/a2/b2/c2.
The ancestor nodes of /a1/b1/c1 and /a2/b2/c2 are the same,
namely {/a1, /a1/b1, /a2, /a2/b2}. I do not see how you can say {"a1",
"a2", "b1", "b2", "c"}. "c" is not one of the terms. "a2" and "b2" by
themselves are not normative identities.
It is also uniquely defined by a URI if a URI
scheme has been applied to the same resources, since all the ancestors
are readily identifiable within the URI.
That's a bit of a contorted way to represent a simple bag of strings.
URIs do not represent bags of strings. Possibly one might choose to
represent a URI as a bag of strings, however, one loses the ordering in
the process. If one wants to identify the specific set of nodes
represented by a URI, it is a simple matter to sequentially strip one
component at a time off the URI, and at each step one has the normative
identity of the next node up the chain until one reaches the root.
Within the policies themselves, there would
generally be no need to include this attribute except possibly for
reporting purposes.
Then what exactly is the problem? Policy, as specified, can be
evaluated deterministically. The mapping of physical entities into
policy resources is outside of the scope of this profile. I do not
see anything broken here.
I was addressing the statement you made that you thought I had a
problem confusing the physical and policy resources. I was showing that
the physical mapping was simply an orthogonal property of the node
which of necessity must include an identity for each of its purposes,
in this case: one for the dept, one for the facilities, and one for the
physical identifier. However, for policies, the physical identifier
need not be used and may be regarded as a resource attribute on the
node entity outside of the policy structures, but available to be
included if necessary.
At this point I fail to understand the purpose of specifically not
using a hierarchical naming scheme in order to identify a set of
resources that will be managed as a hierarchy. I understand that there
may be cases where for some reason it may not be possible or practical
to use such a naming scheme, but in those cases where it is possible
and practical, I do not understand why it would not be a good idea to
use it.
Thanks,
Rich
Daniel;
