[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] [Polar] PH09: New section 7.4.2 Attributes
>Actually, it can be even simpler. Regardless of where the Designator/Selector >is, let return either a bag with one element or just that element when it >only resolves one value. If this is in a function, that function will decide >what to do if it gets a bag with multiple values (ie, it might be able to >handle it, it might be indeterminate, it might be able to skip it and try >other resoltions). *-one-and-only implicit application achieves the same effect, but avoids "runtime" type determination >If you require a designator/selector to act in a special way when it's inside >a function, you muddy the logic of the AD/AS, and if you tell it to always >act as a *-one-and-only you break functions that can deal with (or expect to >get) bags, since there is no way to know that a certain parameter to a certain >function does/doesn't want a bag. You ALWAYS know what parameter the funtion wants - it is in its definition. We agreed not to allow overloading of bag/singleton values > "A bag containing one value is treated as semantically equivalent to a > single value of the specified bag type." Disagree. Bag with one value is NOT the same as a single value. (is String[1] equivalent to String ?) It needs to be transformed and *-one-and_only is the only way to transorm it that we defined. Implicit application of it would only be a simplification for policy writers..
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC