[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Conformance for documents?
Patrick Durusau <patrick@durusau.net> wrote on 12/08/2009 08:36:50 AM: > > That's very helpful. > > So you are saying that the language needs to be reformed to use > expressions vs. evaluators? > That is how I would do it. The top-level task is to take the numerous concepts and terms in the draft specification and rationalize them into formal conformance targets, classes, levels, etc. I've been pushing for having two conformance targets: Expression and Evaluator. > That distinction makes sense to me but then what of all the "portable" > document language in the current draft? > I've thought about this and have some ideas, but I don't think we've discussed or reached consensus on how to treat this formally. The concept of a "portable document" might be expressed: 1) As recommendations. So convert portability requirements into should's. 2) As requirements. So convert portability requirements into shall's. 3)As another conformance class: Portable OpenFormula Expression. 4) Remove from the specification altogether and give it to the ODF Interoperability and Conformance TC to turn into an OpenFormula interoperability guidelines document. 5) Some combination of 1 and 4. The most direct mapping would probably be 3. But if we do so, we need to figure out how that interacts with the small, medium and large function groups. And we would really want to make sure that all implementation-dependent behavior was resolved in the Portable conformance class. It would be unfortunate if the Portable class was merely "more portable" but not fully portable. -Rob > That has been one of my puzzles as it seems to cut across the > distinction you are making between expressions and evaluators. (Note > that I agree a clean separation between those two would do a lot to > improve the current draft.) > > Thanks! > > Patrick > > robert_weir@us.ibm.com wrote: > > Patrick Durusau <patrick@durusau.net> wrote on 12/07/2009 07:03:43 PM: > > > > > >> While reading chapters 1-5 today in a waiting room, ;-), I realized > >> something that we have at least partially discussed but that remains > >> unresolved for the formula work. > >> > >> Granting that in my view we need to consolidate the various requirements > >> > > > > > >> for "applications," we also need to define what it means for a document > >> to conform to OpenFormula. > >> > >> > > > > First thing -- let's erase the word "document" from our thinking, at least > > for OpenFormula. This Part has nothing to do with documents or XML. All > > of the XML/document requirements should be in Part 1 when we define > > table:formula. But OpenFormula is intended to be at a higher level, above > > the encoding and above the document model of ODF. It deals with Unicode > > strings which represent OpenFormula expressions. In theory, OpenFormula > > Expressions should be embeddable in non-XML containers. > > > > This naturally leads to us defining conformance for two things: 1) > > expressions (the analog of documents) and 2) Evalutors (the analog of a > > processor). If you look at the conformance clause in Part 1 you see how > > it invokes these OpenFormula concepts, say in 21.2.4. The former defines > > the static constraints for a string, i.e., the syntax, and the later > > defines the runtime constraints, e.g., the permissible values which an > > expression may be evaluated to. > > > > > > > >> For example, under basic limits we say: > >> > >> > >>> 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, or the ?.? in a cell address > >>> when the sheet name is omitted. > >>> > >>> > >> OK, so for a minimal ODF document that contains a formula, it must at > >> least allow a formula of up to 1024 characters (I am not sure what "ODF > >> interchange format means) "not counting the square brackets around cell > >> addresses, or the ?.? in a cell address when the sheet name is omitted." > >> > >> > > > > So this should say Evaluator rather than "Application". > > > > > >> That is something that could be said about a document and the > >> application that produces it. (I am assuming that the producer of a > >> document doesn't necessarily have the capacity to process such a > >> formula, but that it can insert it in appropriate locations.) > >> > >> > > > > I don't think we need to get into producer conformance in the OpenFormula > > part. It should be enough to treat Expression and Evaluator. In Part 1 > > we can then say that a conformant ODF Spreadsheet Producer shall wrote > > values of OpenFormula that are conformant OpenFormula Expressions. > > > > > >> But then skip a couple of limits and we find: > >> > >> > >>> 1. > >>> > >>> Applications *shall* support at least 7 nesting levels of > >>> > > functions. > > > >> Err, I suspect based on 5.2 Basic Expressions that the nesting is of > >> expressions? Correct? > >> > >> > > > > That sounds right. > > > > > >> Moreover, for a document conformance means up to seven nested > >> expressions, but that doesn't mean that the document producer or > >> consumer does anything with them. Yes? > >> > >> > > > > Nesting can be expressed as a constraint on conforming Expressions. Once > > that is done it is trivial to say that Conforming Evaluators must process > > all conforming Expressions. > > > > > >> I suppose another way to frame this is that the conformance requirements > >> > > > > > >> for an OpenFormula "application" are different from documents that carry > >> > > > > > >> expressions, etc., that conform to the syntax and semantics of > >> OpenFormula. It should be possible to pass OpenDocument documents with > >> OpenFormula conformant formulas to and through ODF 1.2 conformant > >> applications that don't understand or process the formulas. All those > >> applications must do is preserve the formulas that they don't process or > >> > > > > > >> understand. Yes? > >> > >> > > > > I think the intent was that OpenFormula would define syntax for > > Expressions and behavior for Evaluators. In ODF Part 1, we have a number > > of conformance classes, once of which (Conforming ODF Spreadsheet > > Document) should require that Producers write conformant OpenFormula > > Expressions for table:formula and Consumers are conformant OpenFormula > > Evalautors when processsing table:formula attribute. We have other > > conformance classes in Part 1, such as the Extended class or the generic > > OpenDocument Document, where this is not a requirement. But I think the > > user will have the reasonable expectation that formulas will be mutually > > exchangeable among applications that claim to be conforming OpenDocument > > Spreadsheets. In any case, any talk of preserving formulas is out of > > place for Part 2, since nothing here should be describing documents or how > > a document is written. > > > > Does this make sense? > > > > -Rob > > > > > >> Hope everyone is having a great day! > >> > >> Patrick > >> > >> -- > >> 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) > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe from this mail list, you must leave the OASIS TC that > >> generates this mail. Follow this link to all your TCs in OASIS at: > >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > -- > 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) > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]