OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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
>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
>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
type determination

>If you require a designator/selector to act in a special way when it's
>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
>get) bags, since there is no way to know that a certain parameter to a
>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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC