[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Feedback on Chapters 2 - 5?
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 email@example.com 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)