xacml — archive

[Paul Tyson]

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 >