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
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 <>
>
> Date: Sun, 18 May 2008 15:11:49
> To:XACML TC <>
> 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
>
>
