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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: Issue 88, general xpath functions again


All,

I had a look at Craig's original post on this issue with the intention 
of proposing which functions we should import from xpath. Craig's post 
is here:

http://lists.oasis-open.org/archives/xacml/200710/msg00000.html

He proposes these functions as a start:

 - <type>-starts-with
 - <type>-ends-with
 - <type>-contains
 - <type>-substring
 - string-equal-ignore-case

Where <type> is either string or anyURI.

Daniel then proposed that we instead import the string function library 
from xpath 2.

We then discussed the option of a general import of functions from xpath 
and it seems difficult to do. The xpath data model is not similar to 
XACML. It contains entities unnatural to XACML and does type conversions 
on the fly. (Correct me if I am wrong.)

So during the last call we decided to instead import particular 
functions from xpath. And we had found that xpath declares URIs for 
their functions, so we could use those URIs as our identifiers.

Sounds good so far, but I ran into some issues.

For a start I notice that all these functions which Craig proposes are 
not part of the xpath function library itself.

"starts/ends-with", "substring" and "contains" are present, but rely of 
string conversion of their arguments, meaning that there are not 
separate functions for the string and uri variants in xpath. XACML is 
statically typed, so unless we want to change that, we would have to 
redefine these functions into separate string and uri variants in XACML. 
So we end up with just plain XACML functions with no direct mapping to 
xpath.

I could not find the "string-equal-ignore-case" function in xpath. (It 
can probably be achieved with case conversion functions, but I didn't 
look into it.)

So there isn't any direct mapping of these functions to xpath.

I propose that we abandon the idea of mapping xpath functions to XACML. 
The data models are too different to be worth it.

Instead let's just define the functions which Craig proposed ourselves.

Best regards,
Erik



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