MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [xacml] Re: [xacml-comment] 5.31 Element <AttributeSelector>
John Merrells wrote:
>I'd suggest that Implementors of XACML will find it easier to convert a
>string into an XACML type, than to convert a string into an XPath type
>and then into an XACML type.
For the string type, I think there is no need to specify which string type
to
be implemented in the specification. It is up to the implementors.
In turn, that string must be converted into the target XACML data type
(e.g. XMLSchema#boolean) specified in the AttributeSelector element.
This conversion is not clearly specified in the specification. We may
borrow
conversion semantics from XPath 2.0 function and operator draft document
e.g.
xf:boolean-from-string.
Michiharu Kudo
IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
John Merrells
<merrells@jiffyso To: Michiharu Kudoh/Japan/IBM@IBMJP
ftware.com> cc: XACML COMMENT <xacml-comment@lists.oasis-open.org>, XACML TC
<xacml@lists.oasis-open.org>
2002/12/07 06:46 Subject: Re: [xacml-comment] 5.31 Element <AttributeSelector>
Michiharu Kudoh wrote:
>For the type correctness, I don't expect that option 1 always occurs. So
>each implementation should enforce the type correctness. I mean that the
>processor just calls some XPath processor to retrieve the requested node
>set irrespective of the datatype specified in the selector. After some
>string conversions are performed, the processor checks whether each string
>value can be converted to the datatype specified in the selector. Either
>way, this kind of run-time type checking should be implemented for the
case
>of ResourceContent.
>
Good. The specification text needs to be changed. Currently it states:
"In the case where the XPath expression matches attributes in the request
context by AttributeId, it must also match the attribute's data-type with
the selector's DataType. "
>If XPath expression does not include a predicate expression to satisfy
data
>type requirement (Subject/Attribute[AttributeId= '...subject-id' and
>DataType"..."]/AttributeValue), it can select a node that has different
>data type. But I think this is the problem of the policy specification and
>not the problem of the AttributeSelector specification. Certainly, it
would
>be better to add some note about this in the specification.
>
Yes. If the expression author writes an XPath that selects multiple
attribute values
with different DataTypes, then that is their problem.
It would be good for the specification to point this out for expression
writers.
>I think that the semantics of the AttributeSelector should conform to the
>specified version of the XPath. So the conversion functions would be ones
>specified in the corresponding XPath specification. In the case of XPath
>1.0, each conversion (node set to string value and string value to each
>data type) would be the conversion specified in XPath 1.0 even if it may
>have some oddities in it.
>
I'd suggest that Implementors of XACML will find it easier to convert a
string
into an XACML type, than to convert a string into an XPath type and then
into
an XACML type. Fisrtly the XPath conversion functions would have to be
exposed through the XPath processor API. The XPath interface specification
does not mandate this. Also, the string to XACML type constructors should
be readily available. [As the implementor will almost certainly have
implemented
these for expression processing.] Secondly, the specification will have
to provide
a table that maps the XPath type system onto the XACML type system.
>And I could not find any XACML function
>definition that converts "false" string value to False boolean value in
the
>committee specification. Which function are you talking about?
>
Section '4.3 Boolean Functions': "Function: boolean boolean(object) ...
a string is true if and
only if its length is non-zero"
>If the conversion failed, then "Indeterminate" should be returned
>(optionally with some status code such as syntax-error).
>
This statement should be added to the specification.
John
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC