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

[Eike Rathke <erack@sun.com>]

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.


> >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.


> >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..


> >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.

  Eike

-- 
Automatic string conversions considered dangerous. They are the GOTO statements
of spreadsheets.  --Robert Weir on the OpenDocument formula subcommittee's list.