[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] 6.3.7 Infix Operator "<>"
David, David A. Wheeler wrote: >> Under Semantics we say: >> >> >>> Note that if either Left and Right are an error, the result is an >>> error; this operator cannot be used to determine if two errors are the >>> same kind of error. >>> >>> >> Instead of None for constraints, shouldn't the possible values of Left >> or Right exclude an error? >> >> Then if the general rule is violation of constraint is an error then we >> can drop this sentence altogether. >> > > This sentence does not, and is not intended, to > DEFINE the semantic. Instead, it clarifies > an implication of the semantics defined above. That's why it > starts with the text "Note that....". > > The reason this note was added was that users might > think it was okay to compare error values using <>, e.g., > "NA() <> 1/0", which is NOT what <> is good for > (it would return an Error, not TRUE() or FALSE()). > > Is it not clear that this text is a note? I realize that you're > not big on explanatory text, but sometimes implications really > need to be clarified in the spec to make sure people don't do the wrong thing. > > Oh, when you use the prose "Note that ...." you mean this as non-normative text? OK. No, that wasn't clear that you meant for it to be non-normative. But why is there a need to clarify the semantic if the standard defines the inputs to operator to exclude those of type error? (I am assuming there is an error type. I have seen it referenced. But also spoken of as "an error" which may or may not be the same thing.) BTW, is the violation of a constraint always an error (or of type error)? Hope you are having a great day! Patrick -- Patrick Durusau firstname.lastname@example.org Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)