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: Re: [xacml] Issue 88, general XPath function calls


Hi Erik,

Given the concerns about wholesale importing of the XPath functions, then
perhaps we should move back to simply expanding the list of functions in
XACML 3.0 based on the XPath functions (and possibly others) that make
sense?

Regards,
Craig

---------------------------------------------------------------
Craig Forster
Software Engineer
IBM Australia Development Labs
---------------------------------------------------------------


                                                                                                                                   
  From:       Erik Rissanen <erik@axiomatics.com>                                                                                  
                                                                                                                                   
  To:         Craig Forster/Australia/IBM@IBMAU                                                                                    
                                                                                                                                   
  Cc:         XACML TC <xacml@lists.oasis-open.org>                                                                                
                                                                                                                                   
  Date:       10/06/2008 21:27                                                                                                     
                                                                                                                                   
  Subject:    Re: [xacml] Issue 88, general XPath function calls                                                                   
                                                                                                                                   





Hi Craig,

The main problem I have with this is that if W3C has not defined these
identifiers (like they have done for the basic XML schema types), then
we are intruding on their namespace. I couldn't find anything supporting
that they have defined such URIs. But maybe I just didn't find it.

Perhaps the best approach is simply that we "import" all the XPath
functions with our own identifiers, like this:

urn:oasis:tc:xacml:...:xpath-function:upper-case

In this alternative we would make a long list of identifiers and each
case we would refer to a specific function in the XPath spec.

In the end, I am not sure how general we can make the xpath function
import feature, and, indeed, how desirable it is to make it fully general.

With a "fully general import" of xpath functions I mean a feature which
defines a mapping scheme to xpath functions and does not enumerate
specific xpath functions.

A problem with a fully general import is that some functions might not
make sense in XACML.

A benefit might be that as XPath evolves, XACML implementations could
implement new versions of XPath since XACML already supports versioning
of XPath, in which case XACML gain the new functions from the new XPath
version. On the other hand, this might be a problem instead. I am not
sure how robust the XACML versioning of XPath is and how compatible new
version of XPath would be with the function import mapping. Or how
desirable it is that different XACML implementations use different
versions of XPath.

/Erik


Craig Forster wrote:
> Hi Erik,
>
> What about your initial proposal for "[namespace]#[name]"?  The example
in
> this case being "http://www.w3.org/2005/xpath-functions#upper-case";.
>
> Regards,
> Craig
>
> ---------------------------------------------------------------
> Craig Forster
> Software Engineer
> IBM Australia Development Labs
> Argus == https://w3.webahead.ibm.com/w3ki/display/commonauthz/
> HomeBlog == http://blogs.tap.ibm.com/weblogs/craigforster/
> ---------------------------------------------------------------
>
>
>

>   From:       Erik Rissanen <erik@axiomatics.com>

>

>   To:         Craig Forster/Australia/IBM@IBMAU

>

>   Cc:         XACML TC <xacml@lists.oasis-open.org>

>

>   Date:       10/06/2008 07:16 PM

>

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

>

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


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