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


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]