[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, 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]