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 extensions. 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. Daniel.