Re: [xacml] AttributeSelector description and functional requirements

[Erik Rissanen <erik@axiomatics.com>]

Hi Paul,

Ok, I will have a careful look and check that nothing has been lost from 
the previous wording, but I won't have the time to do it today or tomorrow.

Best regards,
Erik

On 2010-01-05 15:25, Tyson, Paul H wrote:
> I'm concerned that the wording does not sufficiently specify the
> expected behavior for xpath processing.  I don't believe any two users
> (or implementors) would come to the same conclusions from reading
> section 5.30 in wd15.
>
>    
>> -----Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>> Sent: Monday, January 04, 2010 10:31
>> To: xacml@lists.oasis-open.org
>> Subject: Re: [xacml] AttributeSelector description and
>> functional requirements
>>
>> Hi Paul,
>>
>> Thanks for the proposal. I think your text is simpler and
>> easier to read than the current one, but I am afraid that it
>> might contain subtle substantiative changes. Just from a
>> quick review I can find at least three substantiative changes
>> to the current text.
>>
>> 1. XACML data type extensions are no longer allowed under
>> your proposal.
>>
>> Currently the spec says:
>>
>> "If the DataType specified in the AttributeSelector is a
>> primitive data type defined in [XF] or [XS], then the value
>> returned by the XPath expression SHALL be converted to the
>> DataType specified in the<AttributeSelector>  using the
>> constructor function below [XF], Section 5, that corresponds
>> to the DataType."
>>
>> Your proposal changes this to
>>
>> "Convert the text value of each selected node to the desired
>> datatype, as specified in the DataType attribute.  Each value
>> shall be constructed using the appropriate constructor
>> function from [XF] Section 5 listed below, corresponding to
>> the specified datatype."
>>
>> Note the difference that your proposal doesn't say "if ...".
>> The effect is that the attribute selector will only work with
>> the specified data types, and not with any extensions.
>>      
> We could add "If the DataType is not one of the primitive types listed,
> then the return values shall be constructed from the nodeset in an
> implementation-defined manner."  As it stands, it is unclear how to get
> from nodesets in the xpath world to typed values in the XACML context.
> The specification should state that this will happen in an
> implementation-defined manner, so there is no expectation of any
> particular standard behavior.
>
>    
>> 2. You have dropped some of the text which specified error
>> behavior. It used to say 'If an error occurs when converting
>> the values returned by the XPath expression to the specified
>> DataType, then the result of the AttributeSelector SHALL be
>> "Indeterminate".' I can't find the corresponding text in your
>> proposal.
>>      
> I did not intend to change the error behavior, so you could add whatever
> wording is necessary to specify the expected behavior.
>
>    
>> 3. You dropped the text about inherited namespaces. Was this
>> an oversight, or does your proposal fix this "automagically"?
>>      
> Yes, it was an oversight.  The constructed XML data structure would
> inherit the namespace context of the<Content>  element.
>
>    
>> I would prefer to keep the text unchanged, rather than make a
>> rewrite at this late stage, unless there is a real error in the text.
>>      
> I do not think the current text is sufficiently well-specified.
> Especially, users who want to use this feature should know exactly what
> the capabilities are.  I had quite a bit of trouble understanding this
> part of the spec when I first looked at it.
>
> Regards,
> --Paul
>