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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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

Subject: RE: [xacml-comment] Multiple decision result of type xpathExpression

> On Sep 05, 2013 1:20 AM, Steven Legg wrote:
> > On 31/08/2013 6:04 AM, Pellerin, Clement wrote:
> > I'm still confused what to do when the element to test is a complex type.
> > For example, how can I accept an element called public knowing
> > it is a complex type and has no significant text value?
> >
> > Let's say I'm satisfied to write the condition in XPath,
> > how can the boolean returned by XPath be used by the Match element?
> It can't. XACML requires that the result of the XPath expression is
> a node-set. Anything else causes an AttributeSelector to generate an
> error. Thus, there are limits to what it is possible to do with XPath
> expressions in XACML.

Yes, this is what I had concluded but I was hoping to be wrong.

It would be an easy extension for XACML 4.
Instead of doing the conversion from Node to String in the AttributeSelector,
the XPath expression could return a String, which could be converted to
the XACML primitive type by the new kind of AttributeSelector.

This still leaves unanswered my opening question.
The XACML request contains a content-selector with an XPath expression
that is known to return a single complexType Node with no text value.
How can I write an efficient XACML expression to test some condition
about that Node?

I believe Node is not a primitive type in XACML 3, and
bag of Nodes are not supported either. This means a nodeset
can only be the result of an intermediate result within the semantics
of a built-in component like AttributeSelector or an intermediate result
of a built-in function like xpath-node-equal.

It seems hopeless to evaluate the content-selector to use the result
as the context node of another XPath expression.
Even writing a custom function seems difficult since it would require
the built-in behavior of AttributeSelector up to the point where the
conversion occurs.

Hopefully, I have overlooked a simple solution,
otherwise this would expose a serious lack of functionality
for such a common use case.

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