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