OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

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


Subject: Re: [office-formula] Constraints and infix ^


David,

David A. Wheeler wrote:
> Patrick Durusau wrote:
>> Err, if we say "implementation defined" isn't there a full stop at 
>> the end of that sentence?
>
> No.  Why would that be so?
>
Well, more on this below but because we have said "implementation 
defined." That means, at least to me, that we haven't defined it.
>> Otherwise, we are contradicting ourselves by then proceeding to 
>> define it.
>>
>> Yes?
>
> No, I don't think so.
>
> "Implementation-defined" means that the implementation is free to
> pick from a set of possibilities, as long as that selection meets the 
> other requirements of the spec.  If the spec limits the set of 
> permissible returns, then it must be one of those possible returns.
>
Oh, no, sorry, at least as I experience standards writing that simply 
isn't true.

If I wanted to say that, I would say:

"There are three (or whatever number) answers to X. Those answers are: 
(list here). For purposes of this standard, each of these answers is 
equivalent to the others for all purposes."

That gets you applications that recognize all the possible answers while 
allowing them to return which ever one they prefer. But they have to 
recognize the others.
>> I really think Rob has the better position to just say 
>> "implementation defined" and then to let it alone.
>
> That may very well be true!  In which case, let's argue about whether 
> it's better to say "implementation defined, anything at all allowed" 
> or "implementation defined, but must be one of the following {list 
> here}".
>
OK, in standards "speak," to say "implementation defined" means that we 
have reached a point that we cannot further define. That was what I was 
keying on and perhaps led to the confusion. For example, the value of a 
table:source-service attribute is implementation specific because we 
cannot know the service names supported by a particular application.

> Where _possible_, I believe we should try to gain agreement on 
> semantics to the extent we can.  Particularly for such a basic 
> operator as "^". In the case of 0^0, I think there are only 3 
> plausible responses: 1, an Error, or 0.  I think we can agree that "" 
> is NOT acceptable, yet if we leave it "implementation-defined" without 
> further limitation, then "" is a permissible result.
>
> There are many reasons to try to _limit_ the amount variation in an 
> "implementation-defined" result, if we can.  For example, it's much 
> easier to create portable spreadsheets if we know that only one of a 
> few possibilities can occur.  If 0^0 could produce a text value 
> containing a weather forecast, it'll be harder to create portable 
> spreadsheets :-).
>
But then it isn't "implementation defined." It is defined by 
OpenFormula, even though it offers a choice of what is returned. And it 
declares that whatever is returned, that the other two must also be 
recognized.

I think that is what you want and not "implementation defined." Yes?

Hope you are having a great day!

Patrick

> --- David A. Wheeler
>
>

-- 
Patrick Durusau 
patrick@durusau.net 
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) 




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