Feedback on Chapters 2 - 5?

[Patrick Durusau <patrick@durusau.net>]

Greetings!

I haven't gotten any feedback on my annotated version of chapters 2 - 5 
of the formula draft.

I think we would all agree that to conform to the OASIS conformance 
requirements, 
http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html, 
that we will need to move Chapter 2 and make it a series of structured 
conformance statements. That much is fairly clear.

What is less clear to me is where should we go in terms of revising the 
formula draft itself? I really do like editing but I can be more 
efficient at it if I have a direction in which I am trying to shape the 
text. ;-)

Let me sketch out what I see as one possible way forward and see if that 
can serve as the starting point for discussion. (Caveat: Yes, yes, I am 
a document format person and have been for the last 20 years. That no 
doubt shapes my point of view and rhetoric. I am not always fully aware 
of it so feel free to comment when you think I am missing something 
important.)

As I understand it, the OpenFormula draft is seeking to define the 
following (in large categories):

1) Types

2) Expression syntax

3) Operators and Functions

And that the semantics of #2 and #3 depend upon the semantics of #1.

Such that when I encounter say an expression that conforms to the 
OpenFormula specification, I know that it must also conform to the 
semantics of the types defined for such expressions.

The reason why I start at such a simple point is to say that conformance 
of an "application/implementation/etc" to OpenFormula seems to me to be 
a two step question.

The first question is: Does this expression/operator/function conform to 
the requirements of the OpenFormula specification?

The second question is: Does some application/implementation/etc process 
that expression/operator/function with the semantics as defined by the 
OpenFormula specification?

That is to say that "conformance" of an application/implementation in 
the absence of some string that conforms to the OpenFormula 
specification isn't an issue.

Let me illustrate how that would change the current draft with regard to 
the "basic limits."

We now say:

>   1.
>
>       Applications *shall* support formulas up to at least 1024
>       characters long, as measured when in ODF interchange format not
>       counting the square brackets around cell addresses, the “.” in a
>       cell address when the sheet name is omitted, namespace prefix,
>       or the initial “=” symbol.
>
>   2.
>
>       Applications *shall* support at least 30 parameters per function
>       when the function prototype permits a list of parameters.
>
>   3.
>
>       Applications *shall* permit strings of ASCII characters of up to
>       32,767 (2^15-1), at least.
>
>   4.
>
>       Applications *shall* support at least 7 nesting levels of functions.
>
One way to re-say those same limits would be:

1. Formulas *can* be up to 1024 characters long, not counting the square 
brackets around cell addresses, the “.” in a cell address when the sheet 
name is omitted, namespace prefix, or the initial “=” symbol.

2. A function *can* contain up to 30 parameters when the function 
accepts a list of parameters.

3. Any ASCII string *can* be up to 32,767 (2^15-1) characters in length.

4. Expressions *can* contain up to 7 nesting levels of functions.

I am *not* necessarily arguing for those particular statements but want 
to use them to illustrate a different way of expressing the limits in 
the current draft.

Note that the use of "can" in ISOesse is "used for statements of 
possibility and capability, whether material, physical or causal."

So, assuming that we adopted such a phrasing of the basic limits (we 
need better separation of them but I haven't covered that here) that:

1. All OpenFormula expressions meet the requirements of #4 in Limits and 
... (whatever else is relevant).

Then, if we want to say something about conforming applications, we then 
reference our conformance statement about expressions and say: All 
conforming applications meet the requirement of processing expressions 
with the semantics as defined by (insert reference) in OpenFormula.

That binds any conforming application just as tightly but stays a bit 
closer to the format.

Comments/suggestions?

Hope everyone is having a great day!

Patrick

PS: Just in the text quoted above there remains to be sorted out if 
formulas are different from expressions?, what do we mean by ASCII 
strings?, issues of interoperability if we really are declaring both a 
floor and ceiling as the discussion on the main list seems to imply, 
that is whether interoperability is harmed by allowing strings > 32,767 
characters in length?

PPS: Apologies for the length of this and several following posts. I am 
about to get part 1 back for another editing round and I need to cover 
as much ground on part 2 as I can before that happens.

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)