Re: [xacml] Issue 88, general XPath function calls

[Erik Rissanen <erik@axiomatics.com>]

Hi Craig and all,

Yes, if we can avoid creating a different element, it would be good to 
avoid it.

But keep in mind that the identification of the xpath function happens 
in a completely different manner than the XACML function. For XACML it 
is like this:

<Apply FunctionId="urn:some:uri::here">

Note that it's a general URI, so the scheme doesn't have to be "urn".

For XPath, if we don't introduce another XML attribute for the function id:

<Apply FunctionId="fn:upper-case">

It becomes ambiguous. Does the latter case mean the xpath function 
"upper-case" in the "fn" namespace, or does it mean an XACML function 
URI identifier with scheme "fn" and scheme specific part "upper-case".

It seems that we either have to define a new element or a new XML 
attribute to avoid this problem. Any suggestions?

mvh Erik

Craig Forster wrote:
> Hi Erik (and all),
>
> I'm not sure if adding an additional element <ApplyXPF> rather than using
> <Apply> is a good idea.  I think using a notation of the the form "
> http://www.w3.org/2005/xpath-functions#upper-case"; is enough, and avoids
> elevating XPath functions above the other functions.
>
> Using <ApplyXPF> wouuld mean we have to create a <FunctionXPF> element as
> well.
>
>   
>>> - 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?
>>>       
>
> I've often wondered about the support for raw XML types as a first-level
> DataType in XACML.  Perhaps this could be added to 3.0?
>
> For example, you could then specify:
>
> <AttributeValue DataType="raw XML identifier">
>       <namespace:Element Attribute="foo" />
> </AttributeValue>
>
> This means the decision engine would be responsible for maintaining the
> semantics of the AttributeValue containing an XML element.  It also means a
> lot more XPath functions (include node-name) would be meaningful in the
> XACML context.
>
> 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:       09/06/2008 00:17                                                                                                    
>                                                                                                                                   
>   Subject:    [xacml] 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
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
>
>