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