Re: [xacml] Condition and FunctionId attribute

[Erik Rissanen <erik@axiomatics.com>]

Regarding #2, we could do that, but in my opinion it is not needed. The 
spec is quite clear on what the condition element does already. There 
are so many ways to write a nonsensical XACML policy, that I don't think 
we should attempt to cover them. ;-)

Regards,
Erik

bill@parducci.net wrote:
> #1 looks like a good solution.
>
> #2 perhaps we should create an annotation in the spec that simply states that non-boolean <Condition> values, while syntactically valid, are unlikely to yield meaningful results
>
> b.
> Sent via BlackBerry by AT&T
>
> -----Original Message-----
> From: Erik Rissanen <erik@axiomatics.com>
>
> Date: Sun, 18 May 2008 15:11:49 
> To:XACML TC <xacml@lists.oasis-open.org>
> Subject: [xacml] 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>