>And are you ok with the performance/size overhead this incurs?
yes
>Also, this means
> that a function will never know about an empty bag and be able to treat it
> differently than an error case, since *-one-and-only is defined to return
> Indeterminate if no values are found.
functions that do not take attribute bags as arguments do not care about
empty bags.
> A second, though much smaller problem, is that it effectively requires
coders
> who create new attribute types to create a *-one-and-only function for
each
> attribute type they invent if they want this behavior
that is correct, if new type is defined every type-* function must be
defined as well
Simon
----- Original Message -----
From: "Seth Proctor" <>
To: "Simon Godik" <>
Cc: <>
Sent: Monday, November 04, 2002 9:59 AM
Subject: Re: [xacml] [Polar] PH09: New section 7.4.2 Attributes
>
> On Mon, Nov 04, 2002 at 09:39:22AM -0800, Simon Godik wrote:
> > use type-one-and-only function:
> >
> > apply string-equal
> > apply string-one-and-only
> > subj-attr-desig attrid string-uri issuer must-be-present
> > attr-val string-uri hello
>
> And are you ok with the performance/size overhead this incurs? Nearly
every
> function in the spec is defined to take single values, which means that
> nearly every AD/AS used in a policy will need this wrapping. Also, this
means
> that a function will never know about an empty bag and be able to treat it
> differently than an error case, since *-one-and-only is defined to return
> Indeterminate if no values are found. When I originally rasised that
issue, the
> TC was adamant that functions should have the ability to differentiate
> between an error case and an empty bag.
>
> A second, though much smaller problem, is that it effectively requires
coders
> who create new attribute types to create a *-one-and-only function for
each
> attribute type they invent if they want this behavior. Why not just have
> language in the spec that lets a PDP do this implicitly, and save on size,
> computation time, complexity, and flexibilty?
>
>
> seth
>
>
>
