I think the current profile suffers a lot from our decision to use it
for both XML/XPath based and attribute based approaches. They are
distinct enough to be done separately, but we did not have enough
cycles to do that.
Maybe it is a good time to split and formalize the attribute -based
approach a bit more - in particular remove any requirements for
identifiers and any references to URI's.
Daniel;
On Feb 18, 2009, at 10:29 AM, Seth Proctor wrote:
>
>> There are many way to create hierarchical structures. If we are
>> to publish anything, I think it should be the most generic one
>> that does not introduce any additional concepts to the XACML (like
>> naming schemes and such).
>
> I agree with Daniel on this point. One of the strengths of the
> XACML core (in my opinion) is that it deals with a policy
> processing model, not the specifics of how XACML systems interact
> with the world around them.
>
> The idea of generic hierarchies is that a PEP should be able to
> name a root, and that should result in a PDP processing multiple
> requests. How that mapping happens is up to some entity outside the
> scope of XACML. It seems to me like what we're really talking about
> in this thread is a profile for specific mechanisms or more
> detailed examples of actual implementation possibilities. I think
> this kind of clarity is great to have, but should be in a separate
> place from the abstract discussion of hierarchies (which I think is
> also Daniel's point). I also think Erik's suggestion makes sense:
> we should continue to look at these details, but move the core docs
> forward separately.
>
>
> seth
