office message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Syntax Comments
- From: robert_weir@us.ibm.com
- To: office-formula@lists.oasis-open.org, office@lists.oasis-open.org
- Date: Mon, 21 Aug 2006 10:33:49 -0400
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.
Namespace_in_XML -- Are we specifically
bringing in what the XML Namespace grammar calls "PrefixedAttName"?
(http://www.w3.org/TR/REC-xml-names/#NT-PrefixedAttName)
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.
5.3 Constant numbers -- the BNF does
not seem to allow negative numbers? Is there a good reason for making
implementations use the prefix - operator to simulate this?
5.4 - Constant strings -- Why do we
escape characters by doubling? XML conventions are to use character
entities, which lend themselves better to XML tools. I guess I'm
wondering if embedded quotes is really a format issue, or a application
UI issue? If it is just an application UI issue, then I'd favor having
the format just use character entities like "
5.5 - Operators -- "Multiply, divide.
Division does not truncate, so 1/2 is equal to 0.5." -- this statement
belongs elsewhere, I think. Maybe an operator semantics section?
Also, the table text sometimes uses the term "priority".
Is this the same as "precedence"? If so, we might
want to use "precedence" throughout. Rather than saying
that precedence can be overridden by using parentheses, how about just
assigning precedence to ()? Call it the "grouping operator",
at highest precedence. That is what C/C++ does/
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.
5.7 -- I'd call this section "Implementation
Extension Functions" or something like that. The fact that this
section is in the Standard means it cannot be Nonstandard <g>. The
issue is not that we have a function using a nonstandard name, it
is that the function is specified. I would merely state that the
extensions functions must be namespace prefixed, and should be globally
unique, with a suggestion that they use the host-name conventions indicated.
I don't think we want those naming conventions as a "must".
If we say, "This prefix must begin with a domain name owned
by the definer" then we lock out those who do not own a domain, or
anonymously defined functions.
"Applications that do not support
a function should compute its result as some Error value other than NA()
when calculating its result." -- I think we want to be more specific
than that, choosing a specific error value and making it a "must".
5.11 - How do we avoid defining a mandated
set of constant error values? Spreadsheets documents store not only
the formulas, but also the last-calculated value at the time of saving.
These calculated values are used by some tools, like light weight
viewers, full-text indexers, script to convert ODF to XHTML, etc., that
do not include a calculation engine with them. So if we want to support
a full-text engine that can find all ODF spreadsheets in a document repository
that contain divide by zero errors (a reasonable use case), then we will
need to require specific constant error values. So, I would make
the values in the table be "must" and call out in the later function
semantics exactly which error value is returned for which error conditions.
5.13 -- "whitespace may not separate
a function name from its initial opening parentheses" -- why the restriction?
Is there any ambiguity from having whitespace there?
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. This is a file format specification.
I wonder if this implementation advice could be moved into a non-normative
appendix, where it can be consolidated and made even better for that purpose?
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]