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] AttributeSelector description and functional requirements


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


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