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

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

Eike Rathke wrote:
>>> 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.
> 
> Well, yes. Still, if we allow lowercase function names, the requirement
> to transliterate them to uppercase using an en-US locale holds.
> Everything else does not make sense.

For _standard_ names, I think you're exactly right.  Originally I even
documented that the standard function names would be [A-Z][A-Z.0-9]*,
but Michael B. didn't like that in the normative text (since it's
really more of note than a user issue).  And while English isn't
"better" than other languages, it wouldn't help to have function
names where each one is from a different language :-).

For non-standard names, an application could all sorts of crazy things;
it COULD automatically detect the situation and do that kind of
switching.  Though I don't see why an implementors would DO that.

An alternative would be to REQUIRE that function names be in uppercase
(case-specific).  One problem is that the OpenDocument specification
itself shows LOWER-case letters in the functions.  We could deprecate
the use of lower-case letters, I suppose.  Accepting lowercase letters
does have the advantage that hand-created files are more likely to be
correctly interpreted.


>> 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
> 
> That's absolutely fine with me and the most logical and convenient way
> to handle it, I just don't know how it fits the OASIS process to say
> "ignore the hidden text when voting" ... let alone processes of other
> standardization bodies like ISO. So we may have to be able to easily
> produce a document without annotations. Just to keep in mind.

I don't know either, though in fact, ISO often accepts ".doc" files
which are often chock-full of hidden text.  Whether they know it
or not, they've already done it many times.  If we simply hand
them a file with the notes not displayed it'll probably be fine;
it would be no different really than a typical .doc file.
If it's TRULY unacceptable, we could use XSLT to remove the text,
though obviously you should NEVER edit the resulting text without
making it nearly impossible to keep the notations in sync,
a result that would be unfortunate and result in lower quality.

--- David A. Wheeler