[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] Proposal of Model for comparing two sequences
Daniel, >Only First is bad because our data model does not guarantee order, I thought that our data model supports sequences as described in Function draft 0.8. I'm not completely sold on our current function set to have bunch of functions such as "string-first", "integer-first", "decimal-first", "date-first", "time-first" etc. For the reiteration of the discussion, I could not follow the discussion when you and Polar had. But through the definitions in the current draft and the discussion on the list, I finally recognized the issue from my viewpoint. Michiharu Kudo IBM Tokyo Research Laboratory, Internet Technology Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428 Daniel Engovatov <dengovatov@cross To: Michiharu Kudoh/Japan/IBM@IBMJP, "'XACML '" <xacml@lists.oasis-open.org> logix.com> cc: Subject: RE: [xacml] Proposal of Model for comparing two sequences 2002/09/12 10:32 >Polar >First, my proposal is meant for applying only to the comparison operator >(meaning that it returns a boolean value), not to arithmetic computation >functions such as integer-subtract. I think we had better distinguish these >two types if we support sequence in our function model. Personally, >arithmetic functions are supposed to implicitly have "OnlyFirst" >ComparisonBase. Only First is bad because our data model does not guarantee order, thus evaluation outcome will not be predictible - we went through this discussion with *-first functions. >If you think that comparison base for arithmetic functions are redundant, >it can be omitted. Then only we have to do is to add a text that the >comparison semantics for integer-subtarct function is "OnlyFirst". Does it >make sense? That was in the first iteration of function specification - implicit runtime check of the return sequence size to be appropriate (indeterminate being returned for a wrong cardinality). I still think this is OK, but had to agree with Polar that compile time type safety is worth it.. We seem to reiterate exactly the same issues in different form over and over.. Indeed, not very obvious.. daniel;
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC