[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Issue 88, general XPath function calls
Hi Craig, Yes, I am leaning towards this as well. What data types and functions are those which we should "import" from XPath? The function list is here: http://www.w3.org/2005/xpath-functions/ When I looked at that list I just noticed that it defines a mapping of the functions to URI identifiers like this (see section 1.1 at the above page): http://www.w3.org/2005/xpath-functions/#max I didn't find this earlier. We can use these as the identifiers, so we won't need to make up our own identifiers nor define an <ApplyXPF> element. Hurray! We still probably have to limit our use of XPath functions to a subset of the full set of XPath functions. Best regards, Erik Craig Forster wrote: > 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]