Thanks for the code samples, Erik.
As far as I can tell, the problem is limited to casting from text to
boolean values. I encountered this problem repeatedly in xslt 1.0
processing, but I never determined whether the defect was in the
specification or the implementations. The problem has disappeared in
xslt 2.0.
The Java 5 xpath api is based on xpath 1.0, so it is not surprising to
see this problem there as well.
However, this is not a severe limitation. It only causes ambiguity in
the case where you want to distinguish between "does this node exist?"
and "does this node have a lexical value corresponding to 'true' for the
xsd:boolean datatype?" The workaround requires the policy author to
write xpath expressions that test the node value against the expected
lexical values (e.g. "true","1", "yes", "false","0", "no") using the
string equality operator.
I modified Erik's sample to test numeric values, and it successfully
evaluated "/ns:Foo/ns:Bar" with a numeric return value for
"".
Therefore, I still believe we should allow any type of xpath expression
in AttributeSelector/@Path, and specify that the result must be returned
to the XACML environment as @DataType. The rules for converting
datatypes from xpath to XACML are well-defined. Aside from the
text-to-boolean problem noted above, this will in general be a useful
and reliable way of testing XML content and structure.
Regards,
--Paul
>