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] Condition semantics

Just to summarize my concerns:

I do agree with Polar that explicit check for the correct length of the
sequence in the arguments may be preferable to raising an error from a
function.  But nothing in the current schema prohibits from doing that if
needed, as was demonstrated in the examples.  

What I do not agree is that we have to make it a requirement for XACML, and
my reason for this is providing support for extensions functions.  They may
have very specific requirements for the content of input arguments.
Providing a standard mechanism for dealing with "unable to compute"
situation, by returning a special reserved value for the result - an error,
seems to me as absolutely essential.

And - I want to treat the standard functions in exactly the same way as the

Thus, since we have this data model - unordered sequence of strings for
anything - from sources like XML, and LDAP - imposed upon us (I also would
have preferred to have separate, explicit *-array data types, separate from
a singleton), performing runtime size check and using the error handling
mechanism to deal with it, is not too high price to pay for clarity and
extensibility of the condition expression and not having to deal with >15
more basic data types.

I also can not agree that errors are such an abomination - most widely used
languages use this model, to certain, albeit limited, success.  We,
regretfully,  need to cater to whatever is widely accepted.


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

Powered by eList eXpress LLC