Patrick Durusau <> 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
