[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]