[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Condition and FunctionId attribute
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]