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 ^


Andreas J Guelzow wrote:
> On Wed, 2009-01-21 at 06:25 -0500, Patrick Durusau wrote:
>>> "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.
> All of this arose from the discussion which value the formula 0^0 should
> return. In this context"recognizing the oterhs doesn't make any sense
> whatsoever.
Well, I am assuming that an application can recognize the case where the 
formula 0^0 occurs in order for us to say anything about it at all.

If that is the case, then surely an application can also recognize one 
of the three results that David wants to define.

That is if an application gets a document with the formula 0^0 and the 
*recorded* result #1, or #2, or #3, why can't it recognize that result 
as being one of the three that we define?

Unless you are presuming that all formulas will be calculated every time 
a document is loaded, which seems like a lot of overhead to me.

Or really for that matter, we could say that since all three results are 
the same, simply replace whatever is found with the one your application 

Well, but I do suspect there are places where substitution may not be 
appropriate but if that is the case, then we need to fall back to 
implementation defined and let it go at that.

What am I missing?

Hope you are having a great day!


Patrick Durusau
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]