Condition and FunctionId attribute

[Erik Rissanen <erik@axiomatics.com>]

All,

I am going through old minutes and editing the specifications according 
to decisions made by the TC.

The minutes from March 13 reference an issue raised on the comments list.

http://lists.oasis-open.org/archives/xacml/200803/msg00009.html
http://lists.oasis-open.org/archives/xacml-comment/200803/msg00005.html

I wasn't on the call that week and I don't recall any discussion of the 
issue since that call, but here is my take on it.

Regarding the first part of the raised issue, I agree that there is a 
typo in the specification text since it still references the FunctionId 
attribute of the <Condition> element, although there is no such 
attribute in 2.0 and 3.0. I propose that we change the text. In the 3.0 
wd 5 it currently says:

--8<--
Valid expressions SHALL be type correct, which means that the types of 
each of the elements contained within <Apply> and <Condition> elements 
SHALL agree with the respective argument types of the function that is 
named by the FunctionId attribute.  The resultant type of the <Apply> or 
<Condition> element SHALL be the resultant type of the function, which 
MAY be narrowed to a primitive data-type, or a bag of a primitive 
data-type, by type-unification.
--8<--

I propose that it should say:

--8<--
Valid expressions SHALL be type correct, which means that the types of 
each of the elements contained within <Apply> elements SHALL agree with 
the respective argument types of the function that is named by the 
FunctionId attribute.  The resultant type of the <Apply> element SHALL 
be the resultant type of the function, which MAY be narrowed to a 
primitive data-type, or a bag of a primitive data-type, by type-unification.
--8<--

I have simply removed the reference to the <Condition> element. (Note 
that a Condition element does not have a resultant type itself, since it 
is the top level holder of a boolean expression in the rule.)

I am planning to post an updated draft later today, so I am making the 
change to the document right away. If the TC objects, I can change it 
again for the next version.

Regarding the second part of the issue raised on the list, it is true 
that the <Condition> element may contain any expression, and that some 
expressions may not make any sense, but we do not have any way to define 
at the schema level what expressions make sense and what do not make sense.

In particular, it would be an error to put an <AttributeValue> with some 
other type than a boolean in the Condition. A boolean AttributeValue 
would be syntactically and semantically correct, though not very useful. 
(Except perhaps during development of policies, when a constant value 
could temporarily replace some other expression.)

I don't think this is a concern and changing it could introduce some 
form of compatibility issue that we could overlook. I propose that we do 
not change the schema.

Regards,
Erik