OASIS ACAL [XACML] TC

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

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com] 
> Sent: Friday, December 18, 2009 03:41
> To: Tyson, Paul H
> Cc: xacml
> Subject: Re: [xacml] New working drafts posted
> 
> Paul, All,
> 
> I wrote a small test program, and it is as I feared it would 
> be. There is a fundamental ambiguity between the modes
> 
> 1. The XACML 2.0 model: "select text content and construct a 
> data type value from the text"
> 
> 2. The model proposed by Paul: "evaluate an xpath and convert 
> the xpath return value data type into an xacml data type"
> 
> These two cannot be combined in the same construct (the attribute
> selector) without some extra XML attribute which 
> differentiates between them. If we want both, I propose we 
> separate them into say 

Paul,

I am not convinced yet. :-)

XACML 2.0 has a specification which says that the xpath selects text 
content, which is then constructed into an XACML data type.

What you instead propose is that an XPath can select any XPath data 
type, and the return value of the xpath is directly the XACML value.

I see value for both approaches, but we cannot mix them in the same 
construct. This is what my code sample says. The same XPath gives two 
different XACML datatype end results depending which approach we use for 
the definition. We cannot mix them (at least not for any given XACML 
data type).

So this opens up the question about replacing the XACML 2.0 approach 
entirely with Paul's new proposal. It has the benefit that more clever 
things can be done with the xpath expression.

However, Paul's approach has the problem that not all XACML data types 
are available in XPath, or at least not in XPath 1. And definitely not 
in XPath 2 either if we consider that XACML is extensible so users could 
define arbitrary data types on their own. So to handle all XACML data 
types, including extensions, we need the "select string content" 
approach from XACML 2.0.

Another benefit with the old selector approach is that it easily handles 
selection of bags of attributes from the XML. I don't know how that 
would work in Paul's approach.

So I think the conclusion should be that we introduce a separate 
construct which is purely XPath based, which takes the XPath return 
value directly as the value of the XACML data type. For XPath 1 only 
string, boolean and integer will be possible return values. For XPath 2 
there will be many more.

And then I think there is ambiguity in the XACML 2.0 attribute selector 
definition as well. It's not clear to me what the "text representation" 
of an element node would be. For intance , would the 
selector "peek" inside the element to get "true"? That seems 
inconsistent, if we imagine a custom extension data type type such as 
, where the 
book on the whole is treated a data type. There we would like to pass 
the entire 

OK, this is too difficult to work out for 3.0.  I don't use this
feature, so I don't have a wide range of realistic use cases.  But from
my experience with xslt and schematron, this will be a significant
limitation for people who want to write complex rules around their XML
content.

A quick fix, as suggested by Erik, would be to add a boolean xml
attribute like "EvaluateXpathAsNodes", which the implementation could
use to make the correct API call.  But this puts an extra burden on the
policy-writer, which I am not sure is necessary, and would introduce an
additional potential source of conflicting directives.  So we should
probably skip over this for now and consider it post-3.0.

I suggest revising the opening paragraph of section 5.30 to something
like:

=======================
The 

Hi Paul,

Ok. I think I prefer to not put in the EvaluateXpathAsNodes into the 
XPathSelector. The behavior of the attribute selector changes in a 
significant, but subtle and hard to understand manner because of this 
attribute, so I think a completely different element is better.

Since we want to stabilize 3.0 now, let's leave that to a later date or 
an additional profile in the next batch of documents.

Given this I think at least Paul and I have reached some kind of 
consensus on the remaining issues. I'll post updated working drafts 
before Christmas so everybody has something to read over the holidays. ;-)

Best regards,
Erik

On 2009-12-21 15:40, Tyson, Paul H wrote:
> OK, this is too difficult to work out for 3.0.  I don't use this
> feature, so I don't have a wide range of realistic use cases.  But from
> my experience with xslt and schematron, this will be a significant
> limitation for people who want to write complex rules around their XML
> content.
>
> A quick fix, as suggested by Erik, would be to add a boolean xml
> attribute like "EvaluateXpathAsNodes", which the implementation could
> use to make the correct API call.  But this puts an extra burden on the
> policy-writer, which I am not sure is necessary, and would introduce an
> additional potential source of conflicting directives.  So we should
> probably skip over this for now and consider it post-3.0.
>
> I suggest revising the opening paragraph of section 5.30 to something
> like:
>
> =======================
> The