Re: [xacml] Issue 88, general xpath functions again

[Craig Forster <cforster@au1.ibm.com>]

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