OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Syntax Comments



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]