Re: [office-formula] Portable document?

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

Patrick Durusau <patrick@durusau.net> wrote on 01/05/2009 11:57:55 AM:
> > I find the notion of a "portable" document both interesting and 
> troubling.
> > My first impression was that any formula that conforms to OpenFormula 
> > would be "portable" but then it appeared that I could have a formula 
> > that conforms to OpenFormula but that isn't "portable." Yes?

The issue is that there you can apply the OpenFormula specification to two different kinds of objects:
1. applications/implementations: Programs that read data in OpenFormula format, and perform calculations using them.
2. documents/data files: Data in OpenFormula format.

For case #1, you want an implementation to implement the specification.  If it does other things, in addition, that's fine... as long as it meets the spec.

But for case #2, a document might very well need a function that is NOT in OpenFormula.  In that case, we want the document to use the specification as much as it can, and then only add what's needed.  In fact, we have a naming scheme for new functions, to make that easier to do.  But then... how can we separate documents that ONLY use what's specified in OpenFormula, vs. those that use OpenFormula but add functions (or require additional size limits, etc.)?

The proposed answer is the term "portable document" - one that ONLY uses the capabilities specified.  That way, you can add specialized functions, while still maximally using what's specified.  OpenFormula has requirements on how to name functions not defined in the spec, so this is not a vacuous requirement.  And since it gives us a way to grow, it's a useful one too.

> > I suppose it is a matter of perspective.

Yes.

> > I see conformance to the 
> > standard as the "test" for portability. By analogy, it would be similar 
> > to having the "small group" but with value limits as part of its 
> > semantics. If I conform to the "small group" with those semantics, then 
> > my document will travel safely to any other application that supports 
> > the "small group" set of functions. Or be, at least to my way of 
> > thinking, "portable."

Yes.   The challenge is, what do we do about documents that include functions that are NOT specified anywhere, but otherwise conform to the spec?  Thus the distinction.

> > PS: Before I forget, is there a reason why we don't cite the W3C 
> > definitions of values types in chapter 4? Granted that some of our 
> > definitions are different but not all of them. Yes?

I don't remember there being any particular reason.
Which spec do you mean by "the" W3C definitions?  The XML spec?

robert_weir:
> I see 'portable document' as a conformance class, but of the document, not 
> the application.

Yes.

> ... We could certainly argue whether the portable conformance belongs in the 
> core ODF 1.2 OpenFormula, or whether we want to defer this to a later 
> "ODF/A" profile.

I think this is important enough to include in the base document.

> Another approach, perhaps complementary, would be to mandate a set of 
> "capabilities" functions whereby an implementation would report its 
> maximum string size, its maximum integer size, what group of functions it 
> supports, etc.  C/C++ has uses a similar approach.  It is easy for a user 
> to create a portable document if they have functions such as 
> maxStringLength(), etc., to conditionalize their formula logic or to 
> report errors.

The problem is that many spreadsheet users aren't as sophisticated as most C/C++ users.
Programming effectively in C or C++ requires that you be able to understand
and correctly concepts such as pointers and memory allocation.  In short,
C and C++ are intended for use by people who are already computing experts.

Spreadsheets are often developed by people who really don't have a good handle
on spreadsheets.... and so if the capabilities aren't adequate, I doubt that adding
additional complexity would help.  There are a large number of papers about how spreadsheets
contain errors of the most elementary kinds: "SUM"s that don't include the range
they're supposed to include, incorrect operations, and so on.
Defining "maxStringLength()" would be easy, but if the max is too small, what do
you expect the developer to do?!?  There are no "while" loops in OpenFormula
(by intent), nor is there a way to define your own functions (future work),
so typical work-arounds implemented by C/C++ programs aren't practical.

If all you want to do is report errors when certain ranges are exceeded, you could probably
do that with the current capabilities... just try to compute using them.
E.G., REPT() can repeat characters, so you can try something like:
IFERROR(LEN(REPT("X";65535))=65535;"Error";"OK")
to report if strings of length 65535 are supported.
Granted, if there's an optimizer, this may not work as expected
(the error might be optimized away)... though you could argue that that
is due to erroneous optimization.

By the way, my profound thanks to Eike Rathke, who's been working hard to address
comments on the spec.

--- David A. Wheeler