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
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