[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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). > 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/XPathExpression.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. 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) 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. 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? > === 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). Best regards, Erik > Regards, > --Paul > > >> -----Original Message----- >> From: Erik Rissanen [mailto:erik@axiomatics.com] >> Sent: Thursday, December 17, 2009 05:47 >> To: xacml >> Subject: [xacml] New working drafts posted >> >> All, >> >> I just posted core wd 14 and associated profiles. This fixes >> all the issues which were posted to the list yesterday. With >> these changes, the only things needed updating are those >> things which Mary will allow, if we would vote on these files. >> >> The changes are >> >> => Fix formatting of all references to OASIS specs >> >> => Fix the typos in hierarchical which Rich posted about >> >> => Update acknowledgments. See my email here: >> http://lists.oasis-open.org/archives/xacml/200912/msg00109.html >> >> => Make combined decision in multiple decision request >> indeterminate if there are obligations or advice >> >> => Fix some other minor formatting issues >> >> => Fix cross references in schema files >> >> => Fix references to XACML 1.0 and 1.1 in SAML profile schema files >> >> => Update copyright date to 2009 in SAML profile schema files >> >> BTW, I just realized that there is no copyright statement in >> the core schema. I think there was some discussion a few >> years ago about the 2.0 schema files and a copyright >> statement which was missing, so I added in one for 3.0 core. >> I am attaching the updated file with this email. >> >> Best regards, >> Erik >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]