[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Issue 88, general xpath functions again
Hi Erik, Thanks for summarising the conversations to date. I agree that our investigations have shown that generally importing XPath functions is incompatible with the XACML data model. So apart from the functions I've listed, does anyone else have suggestions about what other new functions are needed for 3.0? Regards, Craig --------------------------------------------------------------- Craig Forster Software Engineer IBM Australia Development Labs --------------------------------------------------------------- From: Erik Rissanen <erik@axiomatics.com> To: XACML TC <xacml@lists.oasis-open.org> Date: 25/06/2008 02:09 Subject: [xacml] 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 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]