[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] New working drafts posted
See inline, On 12/17/2009 06:55 PM, Tyson, Paul H wrote: >>> 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. > Do you refer to String evaluate(InputSource source) This is just a shorthand for evaluate(source, XPathConstants.STRING) >> 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. > Yes, maybe so. When I re-read it now, it appears so. The first time I read it, I had the impression that this was not the case. I'll try it out later. >> 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. > Maybe. I need to check this, but now that I read the API once more, I think you are right. Though, we can't use the @Datatyp directly since XACML has more data types than XPath (at least XPath 1). And XACML uses URIs, which need to be converted to QNames. Anyway, that should be workable. >> 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(). > This could be a problem with the java xpath API. It differentiates between NODE and NODESET as return types, but with some luck one can always use NODESET and get a singleton set in case there is a single node. >> >> >> >>> === 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. > Yes, the content belongs to the XACML world, but I think it is perfectly fine as a place holder. A policy belongs to the XACML world and having a content element as the starting point of expressions seems fine for me. I am not sure if I understand what you propose. The data model is part of XPath 2.0. Will your approach work with 1.0? From my experience about using the java xpath API, it requires a DOM and absolute xpaths don't work correctly if the document element of the DOM is not set. I see in the spec for the XPath data model that a document node is not required to contain exactly one element child, but what would "/" resolve to in your approach? Best regards, Erik
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]