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] New working drafts posted


See inline. 

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com] 
> Sent: Thursday, December 17, 2009 08:19
> To: Tyson, Paul H
> Cc: xacml
> Subject: Re: [xacml] New working drafts posted
> 
> Thanks Paul,
> 
> See inline.
> 
> On 2009-12-17 14:59, Tyson, Paul H wrote:
> > There are still problems with xpath, AttributeSelector, and 
> Content.  
> > In section 5.30 of the core spec wd14:
> >
> > 1. Lines 2454/2457 appear to repeat the meaning of lines 2431/2439.
> > Lines 2454/2457 should be deleted.
> >    
> 
> Could you make a reference to a section or copy/paste text. 
> The line numbers don't appear to match my view of the 
> document (MS Word 2007).
> 

The redundant paragraph is the one that immediately follows the list of
primitive datatypes in section 5.30.

> > 2. Lines 2458/2461 unnecessarily restrict the @Path xpath 
> expressions 
> > to those that select nodes from an XML document.  It would exclude 
> > node comparisons, counting, positional queries, and other useful 
> > expressions for testing XML structure.  Erik thought this would be 
> > difficult to implement because of ambiguous return types from these 
> > expressions, but in fact they will be better-defined than 
> XML nodes, 
> > which will appear as string values when put into the XACML 
> context.  
> > The @DataType attribute of AttributeSelector will control 
> the return 
> > type to the XACML context, and if this type cannot be 
> constructed from 
> > the return value of the xpath expression the application 
> must signal 
> > an error.  But this will not be the common case, and when it does 
> > arise the policy author can adjust the xpath expression to cast the 
> > value to a suitable argument type for the constructor 
> function.  As I 
> > suggested earlier, this paragraph should be replaced with:
> >    
> 
> I tried to explain earlier that it is not as simple as that 
> the @Datatype of the attribute selector can control this. 
> Let's assume that I implement the selector with the Java 
> XPath API. The method for evaluating an xpath looks like this:
> 
> http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/xpath/XPathE
> xpression.html#evaluate%28org.xml.sax.InputSource,%20javax.xml
.namespace.QName%29
> 
> Object evaluate(InputSource source, QName returnType)
>                  throws XPathExpressionException
> 
> I have to specify the return type of the xpath expression 
> when I evaluate it. This is not the same thing as the return 
> type of the attribute selector, which the @Datatype denotes.

There is also an evaluate() method without the return type, so the
client application could sort out the datatype if it wanted to.

> 
> Consider this example:
> 
> <Content>
> <Foo>true<Foo>
> </Content>
> 
> <AttributeSelector Datatype="...boolean" Path="Foo/text()">
> 
> then the xpath expression will evaluate to the string "true", 
> which according to the XACML spec has to be cast into an 
> XACML boolean. I must invoke the xpath evaluation with:
> 
> evaluate(source, XPathConstants.STRING)

The question is, does the the xpath implementation try to cast the
results to the desired type?  I would assume so, in which case you can
use the AttributeSelector/@DataType as the return type.

> 
> However, look at this:
> 
> <AttributeSelector Datatype="...boolean" Path="self::node() = Foo">
> 
> In this case the data type of the selector is still an XACML boolean. 
> The difference is that the xpath expression returns an XPath 
> boolean, which means I have to evaluate it with:
> 
> evaluate(source, XPathConstants.BOOLEAN)
> 
> If the implementation uses the wrong form, the XPath API will 
> throw an exception.

The XACML application cannot go wrong by using the @DataType value
everywhere.

> 
> I don't know whether we should consider this a flaw in the 
> java XPath API, or a more fundamental type checking issue, 
> but in either case it is a practical difficulty for 
> implementation. We could add a @PathReturnType attribute to 
> the selector, and then the implementation would know. Any 
> other suggestion?

I'm not in favor of an additional attribute.  If the underlying xpath
api or implementation has problems, then it will throw nuisance errors
and will perhaps be unusable.  But that should not affect or restrict
how we write XACML policies and make XACML requests.

The bigger problem might be how to get a sequence of values, without
knowing in advance whether an xpath expression will return one or
several values.  The most useful API would always return a sequence from
evaluate().

> 
> 
> 
> > === proposed wd14 lines 2458/2461 ===
> > If the XPath expression selects a sequence of XML nodes (text, 
> > attribute, element, processing instruction, or comment nodes), then 
> > the string representation of the value of each node MUST be 
> converted 
> > to an attribute value of the specified data-type, and the result of 
> > the AttributeSelector is the bag of the attribute values generated 
> > from all the selected nodes.
> > =====================================
> >
> > 3. Lines 2466/2469 regarding the definition of the XML 
> infoset that is 
> > subject to xpath processing:  The xacml:Content element does not 
> > belong in this infoset.  The XML that is subject to xpath 
> evaluation 
> > should be the sequence of nodes that are the children of the 
> > xacml:Content element.  This can include zero or more elements, 
> > comments, processing instructions, and text nodes.  I propose 
> > replacing the first sentence of this paragraph with:
> >
> > === proposed wd14 lines 2466/2467 ===
> > The Xpath expression MUST be evaluated in a context which is 
> > equivalent to a node sequence formed of all the child nodes of 
> > the<Content> element, and all the attributes and 
> descendants of those nodes.
> > Namespace declarations ... [unchanged] 
> > ======================================
> >
> > Note that this makes user-defined attributes of xacml:Content 
> > invisible to xpath expressions, so we should consider removing 
> > "anyAttribute" from the schema definition of xacml:Content.
> >    
> 
> I think we want the <Content> element since otherwise it's 
> not going to be a valid stand alone XML document. (XML 
> requires a single document element, righ?) If there is not a 
> single document element, the aboslute xpath "/" becomes 
> undefined. There is no harm having the content element there. 
> In fact, it could even be beneficial to use the XML 
> attributes of the <Content> element since XML attributes have 
> a slightly more compact encoding form than elements (which 
> repeat the name of the element at the end tag).
> 

I think that xacml:Content belongs in the XACML world, and its children
belong in the user's world.  The <Content> element is a wrapper that
should not be visible or accessible during policy evaluation.

We should define this in terms of the xpath data model (XDM) instance
that will be created from xacml:Content, which will be the subject of
any xpath expression evaluations.  The "sequence of nodes" I originally
proposed will not work.  I propose the model be specified as:

1. A new document node will be created for each <Content> element.
2. All xml content of the xacml:Content element will be parsed and put
into the xpath data model as specified by the xpath data model
specification (http://www.w3.org/TR/xpath-datamodel).

(This is a notional specification only--there is no requirement that the
implementation actually do this--only that the results of xpath
evaluation are the same as if this had been done.)

Note that this could result in a valid XDM structure that would be
malformed XML, because the document node could have several element
children. (In an XDM constructed from valid XML, the document node would
have only one element child--the document element.)  I do not see
anything that prohibits this, either in the XDM or the Xpath
specification.

Regards,
--Paul 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]