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


Hi Paul,

See inline.

On 12/16/2009 04:10 PM, Tyson, Paul H wrote:
> Great work, Erik. Thanks.
>
> Some comments inline.
>
>    
>> -----Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>> Sent: Tuesday, December 15, 2009 13:30
>> To: xacml
>> Subject: [xacml] Updated working drafts posted
>>
>>
>> =>  Regarding the XPath node match, equal and count functions,
>> I cannot think of any simple general transformation into an
>> equivalent attribute selector and I have not received any
>> proposal from other TC members, so I am leaving the xpath
>> node functions as they are.
>>      
> I did this for xpath-node-count, but haven't yet defined the other two.
> I will try to have these defined before the next TC meeting.
>    

I was hoping that this version would be it. :-) The next TC meeting 
after this week is in January, and I was hoping we can go public review 
early January. Can't we just stick with the current text?


>> =>  I have not seen any proposals for names for the new XML
>> attributes in attribute selector, so I am going with this:
>> The old RequestContextPath is renamed to simply "Path" and
>> the new attribute is called "ContextSelectorId".
>>      
> I had thought that "RequestContextPath" would be retained for backward
> compatibility.  The new "Path" attribute would be the preferred synonym.
>    

I saw this proposal from you in the minutes, but I don't see or recall 
any general decision on it. We don't have synonyms for anything else 
which changed from the 2.0 schema so I don't see any need for this 
special case.
>> =>  Paul posted examples of some clever use of an
>> AttributeSelector. See here for instance:
>>
>> http://wiki.oasis-open.org/xacml/XpathDiscussion?action=recall&rev=10
>>
>> I think that kind of use is not allowed by the current
>> definition of AttributeSelector since it requires that the
>> xpath selects textual content from a node. See the following
>> piece from the spec:
>>
>> --8<--
>> Each node selected by the specified XPath expression MUST be
>> a text node, an attribute node, an element node, a processing
>> instruction node or a comment node. 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.
>>
>> If the node selected by the specified XPath expression is not
>> one of those listed above (i.e. a text node, an attribute
>> node, a processing instruction node or a comment node), then
>> the result of the AttributeSelector SHALL be "Indeterminate"
>> with a StatusCode value of
>> "urn:oasis:names:tc:xacml:1.0:status:syntax-error".
>> --8<--
>>      
> I don't know what the motivation was for this restriction, but it
> appears to be unnecessary.  I suggest revising the first paragraph
> (quoted above) to:
>
> === proposed ===
> 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.
> =================
>
> The XML structure may be just as important as its content, and if you
> limit xpath to just node selections you will prevent many useful tests
> (e.g., for existence, position, or number of nodes).
>
> Any xpath processor is going to be capable of evaluating non-node xpath
> expressions as well as node selectors, so I do not see this as an
> implementation barrier.  If AttributeSelector is implemented at all, it
> should handle the full range of xpath 1.0 or 2.0.
>
>    
>> Paul's xpath expression on the other hand evaluate to Boolean
>> or integer data types within the xpath language, rather than
>> selecting nodes, so they don't conform to this specification
>> and are not allowed.
>>      
> All types of xpath expression should be allowed, as described above.
>
>    
>> I thought about dropping this restriction, but when I look at
>> for instance the Java 5 XPath API, it is unclear to me how
>> the more generalized selector could be implemented. The API
>> requires that the Xpath evaluation method is invoked with a
>> parameter which specifies the return type of the xpath
>> expression. There are a couple of supported data types such
>> as node set, string and Boolean. In other words, if the XACML
>> implementation evaluates the xpath expression, it must know
>> beforehand whether it expects a Boolean or a string, which
>> would depend on the form of the expression.
>>      
> The AttributeSelector must define the expected datatype, so the XACML
> application would be able to specify the return type using the Java 5
> xpath API.
>    

Can you propose what this would look like? We need to add some extra XML 
attribute to the selector, for instance to tell between when an xpath 
expression selects text with the content "true", which can be cast to a 
boolean, and the case when the xpath expression evaluates directly to an 
XPath boolean data type, which must be treated differently in the java 
xpath API.

>> I haven't tested, but when I read documentation on the web,
>> it says that the XPath API will throw an exception if the
>> conversion between the actual and expected return type cannot
>> be made. So it seems unclear to me how to fix this, so I am
>> leaving it as it is.
>>      
> Any errors would be due to defects in the policy or the xml instance.  I
> don't see that anything would be underspecified.
>    

What I meant is that there is no way to automatically detect the right 
type from in the java xpath API. If you don't know whether the xpath 
selects text, selects a node or evaluates to a boolean, you will get 
exceptions from the API when you evaluate the xpath. (Though I did not 
actually test this.)

> It is very important to be able to use general xpath expressions to test
> structural as well as content information.  I don't think we should
> exclude this functionality.
>
> Regards,
> --Paul
>    



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