[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, Ok, than I understand you. Which functions do you think we need for using this data type? Also, we already have the <Content> element which contains raw XML. What do you want to do which cannot be done with the <Content> element and the current xpath functions? /Erik Craig Forster wrote: > Hi Erik, > > I wasn't proposing anything this complex, just a simple DataType identifier > that signifies XML is contained within. Something like > "urn:oasis:names:tc:xacml:3.0:data-types:xml". > > The decision engine would then need to keep these types as XML blobs (DOM > objects, probably), and then made available to whatever functions require > it. Such functions would include whichever XPath functions, such as > node-count, require an XML element as an input. > > Would this be useful, as opposed to defining a domain-specific DataType for > the XML element contained within? I'm not sure on that one... I do think > we need better native handling of raw XML data though, even if it's a set > of conventions that we establish and use in our core profiles. > > 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 07:28 PM > > Subject: Re: [xacml] Issue 88, general XPath function calls > > > > > > > Hi Craig and all, > > This is an interesting idea. My initial worry is that the XML identifier > is not enough. A PDP would always have to implement actual processing > logic for any particular data type and function. How would this be > handled do you think? How general should it be? > > In the end I think we would have to enumerate the types that an > implementation has to support, or (equivalently) refer to a > specification which does so. > > What do you mean when you say "This means the decision engine would be > responsible for maintaining the semantics of the AttributeValue > containing an XML element"? I didn't understand this. And perhaps you > could elaborate on what you mean with "Raw XML types". Do you mean the > types defined in XML schema here: http://www.w3.org/TR/xmlschema-2/ > > How would the types be identified? With the normal URIs such as > http://www.w3.org/2001/XMLSchema#string? > > How would what you propose be different from that we just enumerate more > of these URIs in the standard? > > Regards, > Erik > > Craig Forster wrote: > >> 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 >> >> >> >> >> >> > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]