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, no. It's much more than just a simple if(size == 1) check that
>we're talking about, since there's an extra Apply, an extra function
>evaluation, an extra etc...not to mention the extra bits on disk to store
>a policy with all that extra stuff in it. Using the one-and-only functions
>results in a much more expensive evaluation all around.

Maybe.  In mine it does not do that at all, but I agree it could.

>If the way this mapping is done is through an explicit use of the
>functions, you cannot do an implicit application of this functionality and
>still produce an interoperable PDP. Ie, it will treat the same policy data
>differently in some cases than other PDPs. This is Bad. Either the spec is
>explicit about a way to treat these values implicitly, or the one-and-only
>functions are used, which is expensive. It does much more than just "avoid
>an extra value copy"

If we state "Designator used as an argument to a function that requires a
sigleton value, SHALL be treated as if an implicit *-one-and-only function
was applied to it"  it will be interoperable and explicit and implemetation
can optimize this particular operation to avoid all the overhead of the
function application.

Smart implementation will also optimize the explicit application of this
this funcition, if we do not accept this interpretation.  Nobody is going to
parse policy XML in the runtime and if somebody does, this extra call is the
least of his worries performance-wise.
We have the data model that necesseraly returns bags and there is no way
around it as we do not specify (and should not specify) how the virtual
context is structured.  


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

Powered by eList eXpress LLC