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 function calls


All,

In issue 88 it has been proposed that all functions from XPath 2.0 be 
made available in XACML by means of a general mechanism.

I have looked at this issue and it seems to be doable.

Function calls in XPath 2 are defined here:

http://www.w3.org/TR/xpath20/#id-function-calls

In short, the call is written as a qname followed by its arguments. Such 
as this:

my:three-argument-function(1, 2, 3)

It would be simple to define some form of syntax which means that a 
particular XPath function is evaluated. It could naturally be done in a 
number of different ways.

The XPath 2 function library is defined here:

http://www.w3.org/TR/xquery-operators/


Potential issues I see:

- Do all the functions and data types make sense to XACML?

For instance, there is function called fn:node-name which returns the 
name of a DOM node. Would including this function and its associated 
data types make sense in XACML?

Another one is fn:error which raises an error. (BTW, some form of error 
raising capability would be good to have in XACML, for instance to make 
assertions about expected attributes in the request.)

Perhaps we should enumerate a list of functions and data types which we 
think make sense?

- XPath does some type conversion to function arguments. Are we 
comfortable with this, considering that XACML has been strictly typed?

- Are we happy with qnames as identifiers? Traditionally XACML has not 
done that. Perhaps we could create URIs from the qnames using 
namespace#name such as done in the XMLSchema data types. For instance 
http://www.w3.org/2005/xpath-functions#upper-case would convert a string 
to upper case. I searched the spec for a convention like this, but I 
couldn't find one, so we should probably not make up one.

BTW, the daytime and yearmonth durations are defined in the "op:" 
namespace. This namespace does not have a definition and the functions 
are not intended to be callable by users. Sadly, I was hoping that we 
would get our new function identifiers for the duration functions from 
the xpath spec.

So, assuming that we can go with qnames, we could do something like this:

<ApplyXPF xmlns:fn="http://www.w3.org/2005/xpath-functions"; 
function="fn:upper-case">
  <... Some XACML expression evaluation to a string here ... >
</ApplyXPF>

(Alternatively we could overload the regular <Apply> to also invoke 
XPath functions, but I think we should not to keep things tidier.)

If we don't like qnames, we could do something like this:

<ApplyXPF namespace="http://www.w3.org/2005/xpath-functions"; 
name="upper-case">
  <... Some XACML expression evaluation to a string here ... >
</ApplyXPF>

The advantage is that qnames/namespaces can be tricky to work with. For 
instance unless one is careful they can be lost in XML signature c14n 
and they can occur anywhere in the document, not just the <ApplyXP> 
element, meaning that roundtripping through some internal format is more 
difficult to implement. On the other hand a namespace declaration can be 
reused in the whole XACML document, making the document more readable 
and requiring less bytes for transport/storage.

Best regards,
Erik



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