Re: [office-formula] Portable "documents"

[robert_weir@us.ibm.com]

Patrick Durusau <patrick@durusau.net> wrote on 12/15/2009 08:59:27 AM:

> 
> My major concern at present is what to do with the notion of "portable 
> documents."
> 
> First, understand that my role is really to help the formula SC and the 
> ODF TC to say what they want to say. I may or may not agree and will 
> argue for my position but ultimately, my task is one of expressing the 
> committee's view in standards prose.

So we start with two conformance targets:  formulas and formula 
processors.  Part 2 defines requirements and recommendations (shall's and 
should's) for these two conformance targets.

There are then a set of additional requirements and recommendations that 
pertain to "portable documents".  So on the face, this sounds like a 
conformance class.  Certainly there are exceptions, where the portable 
document constraint is constraining user behavior, but for the most part 
these seem like coherent requirements, or can easily be rewritten to be 
so.

In any case, we have a range of ways to treat this:

1) Have two expression conformance classes: formula and portable formula. 
Remove any portability constraint that is not a testable assertion about 
the static properties of a formula string. Watch out especially for the 
ones that say "Portable documents shall not depend on X".  This appears to 
be different than just "Portable documents shall not use/contain X".  I 
think these are saying (essentially) that the results of the formula 
should not be able to determine whether or not X exists, or that the 
results of the formula shall not differ based on the presence or absence 
of X".  I understand the concept, but find it hard to express in testable 
terms.

2) Have a single conformance class, and turn all portability constraints 
into conformance requirements (again removing those that are not 
statically testable).  So all conforming formulas must adhere to these 
requirements.

3) Keep conformance as it is and move all portable document statements to 
an informative annex or to a separate document (not part of ODF 1.2).


My preference would be for #2.  I don't want to make more work for 
implementations than necessary, but I think that achieving some level of 
portability should be a necessary goal of this work.  So if portability 
requires a given constraint, then why wouldn't we make it a requirement?

The reality is we can define a "common intersection" of spreadsheet 
functionality that would be widely portable, although no spreadsheet 
application is likely to constrain users to using only portable 
constructs.  And if we define a broader subset of functionality in 
OpenFormula then it will allow some formulas that will not be portable. 
This is a common situation with other standards, especially computer 
language standards.  In those cases, it was common to define the opposite 
of portability constraints.

For example, instead of saying "Portable programs shall not dereference a 
null pointer", we would say "The value of a dereferenced null pointer is 
undefined".  Or instead of saying "A portable program shall not depend on 
the size of an integer" we would say "The size of an integer is 
implementation-defined".  So, the concept of a portable program was not 
explicitly stated, although in practice it could be derived:

1) Avoid all undefined behaviors
2) Do not depend on any implementation-defined or implementation-dependent 
behaviors

I wonder if an approach like that might result in a tighter specification? 
 In other words, rephrase all portability constraints as positive 
statements about undefined, implementation-defined and 
implementation-dependent behaviors?


-Rob