Re: [office-formula] Re: [office] Syntax Comments (Weir)

["David A. Wheeler" <dwheeler@dwheeler.com>]

Eike Rathke wrote:
> Hi David,
>
> On Mon, Aug 21, 2006 at 19:16:16 -0400, David A. Wheeler wrote:
>
>   
>>> 5.1 --   We seem to say first that the namespace is optional, but then 
>>> that an application should not include this namespace, as it is 
>>> unnecessary.  I probably don't disagree with this section, just a little confused.
>>>       
>> Generally, a leading "=" is all you need.  But since OTHER formats will 
>> use a
>> namespace, it seems inconsistent to not have a name for the default 
>> formula format too.
>> Which is why it's worded that way.
>>     
>
> Well, ODF 1.0 section 8.3.1 "Formula" says about the table:formula
> attribute
>
> | Every formula should begin with a namespace prefix
>
> While the "should" is not written in uppercase bold letters, for which
> btw is no destinction anymore in the ISO standard, I don't see a reason
> to not interpret it as a SHOULD according to RFC 2119. Encountering the
> ODFF namespace clearly signals a conformance intended by the writing
> application, while the absence may be because of sloppiness or not, or
> an application written prior to the ODFF standard, you don't know.
>
>   
>> Can you suggest a better wording?  Or do you think that the 
>> inconsistency is okay?
>>     
>
> I suggest:
>
> The namespace tells the reading application how to treat formula content
> written by a specific application or an application conforming to
> a certain dialect of this formula language. Though the namespace is not
> strictly mandatory as per ODF 1.0 section 8.3.1 "Formula", it is
> strongly recommended to (use it|name it|make use of|whatever / pick
> correct English term) to prevent misinterpretation.
>   

Actually, the reading I got from the "office" mailing list was that many 
people
did NOT like having namespace prefixes in attributes, AT ALL.
There sure was a lot of heat about it. While it DOES solve a problem,
if there is a case where it's normally NOT needed, many would
prefer that we omit it.  And clearly it's omittable here.

So I think we should say that if when an OpenFormula formula is contained
in the OpenDocument attributes table:formula or text:formula, applications
MAY but SHOULD NOT use a namespace prefix, and immediately begin with "=".
We should still document a namespace, etc., for those who want to use
OpenFormula in other contexts.  You could even have backwards-incompatible
changes without the namespace marker (though I know of no
reason that will ever be needed or even desired) - the OpenDocument
version number is sufficient for identifying a specific version, if needed.

Maybe we should just omit the namespace stuff from the BNF, and
say that in text.  It's likely to confuse people if it's a SHOULD NOT 
use, but
it's in the BNF.

>>> 5.2 -- Forced Recalculation, can that be done in other ways, without 
>>> touching the syntax?  For example, some functions could be declared to 
>>> be transient, like RAND() giving different values on each recalc, 
>>> independently of any special marker.  If we can have some notion of 
>>> transient functions, then we could allow implementations to expose 
>>> that property to custom extensions functions as well, so these 
>>> functions could declare if they are free of side effects or not.
>>>       
>> Many functions are volatile, but that's not the issue in view.
>> This solves a different problem, I believe. The problem as I understand it
>> is that some functions can pick off arbitrary cells without there
>> being an obvious dependency, so it's helpful to be able to force a recalc
>> that wouldn't be determined from the usual dependency map.
>>
>> Eike: Since you're the original proposer of this, can you step in to explain
>> this better than I have?
>>     
>
> It's basically about asynchronous function results and/or macros to be
> called whenever a predecessor changes its value. Given a macro function
> call =MYMACRO(A1) in cell ZZ65432, for example, and the view
> encompassing around A1:K35, changing the value in A1 does not
> necessarily lead to a recalculation of ZZ65432 if no other formula cell
> depends on its result until the cell is viewed or otherwise neeeded. If
> MYMACRO() should record each new value in a log file it would miss all
> values if there was no means to force the recalculation. ==MYMACRO()
> solves that.
>
> Note that this is not about volatile or transient functions. Also these are only recalculated when needed.
>   
Thanks, that's much better than what I wrote.

>   
>>> 5.6 -- Is there a reason why predefined function names are limited to 
>>> ASCII characters?  In practice this may be true, as a fact.  But do we 
>>> lose anything by removing that restriction?  I'm thinking especially 
>>> of UOF/ODF work going forward, where there may be predefined functions 
>>> in Chinese characters.
>>>       
>> Well, it's nice to be consistent, but that's the only reason.
>>
>> Unless someone objects, let's transform this into a non-normative
>> (and normally unprinted) note.
>>     
>
> Seconded. Or not. Just this: while this is fine in general and
> multi-lingual applications need to be able to handle non-ASCII letters
> anyway, there's just a practical implication especially together with
> the case-insensitiveness that can't even be solved by restricting to the
> ASCII character set. Consider the Turkish locale, where there exist both
> lower case and upper case versions of each 'I' without dot and 'i' with
> dot. An application reading a function name intended to be a native
> Turkish language function name using a lowercase 'i' with dot will never
> get it right converting to uppercase I with dot if it doesn't use
> a Turkish transliteration. Vice versa, an application running in
> a Turkish locale may convert a lowercase 'i' with dot to an uppercase
> I with dot, and then would not match an intended IF(), for example. So
> we might even have to impose yet another restriction that function names
> are always to be converted to uppercase using an en-US transliteration.
> Which of course does not fit with any UOF/ODF intentions.
>   

Well, standard function names are automatically translated to a single name
when stored, no matter what is displayed.  For nonstandard names,
the application itself would hopefully know how it encodes it.



>>> Comments throughout -- there is a lot of good implementation advice 
>>> given in the text, along the lines of "implementations may do X Y and 
>>> Z in the UI, so long as the format written out is as specified".  This 
>>> is good info, but it is not normative, and does break the flow of the 
>>> specification a bit, in my opinion.  In the end, a user interface can 
>>> do whatever they want.
>>>       
>> That's fair, we could definitely remove that text.
>>     
>
> For a standard they're non-normative anyway, and I also don't think that
> another standardization body would accept them, even not as appendix. We
> may provide two documents though, a standard specification, and an
> annotated version including all the comments, bells and whistles.
>   

It is my intent to make all the shaded notes become hidden text (they'd 
depend on a
single variable, so they could be displayed and undisplayed easily), though
still in the .odt file. The hidden text would not be considered part of the
standard for voting purposes, but could be revealed whenever desired.  
That way:
1. The annotations will NOT be considered part of the formal spec
2. We have an annotated version, trivially printed and shown
3. The annotations are more likely to be in sync with the spec

--- David A. Wheeler