[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-comment] OpenFormula (OpenOFormula?)- I'm working on a draft.
Seems like sunlight is beginning to pierce through the clouds :) David, keep up the good work! If it's developed as an OpenFormula that can be interoperated between systems, I'd like to see such OpenFormula to not just solve OpenOffice's formula default representational issues, but also be something that can be used to exchange formulas amongst disparate systems other than OO systems. I see such OpenFormula as a means of representing the mathematical truths and relationships bewteen variables for all computable values the variables can represent. If we do that, and leave individual implementations of such an OpenFormula spec to annotate their local deviations, optimisations, short-cuts, type-conversions, rounding defaults, etc, then we'll be interoperating at the mathematical formula level (for all real, computable values of x, y, etc), which is what we'd need in real life. Such a spec, I hope, would define the standardized treatment of valid and invalid value inputs to functions (e.g. how to return 1/0, 0/0, etc), standardized symbolic constants for mathematics, perhaps also finance, physics, engineering etc (e.g. PI=3.1415926 may be true when evaluated on a C-floating-point package, but will be false when evaluated on a C-double-package, where PI is the conceptual pi constant). I also expect such a spec to be precise, and avoid at all temptations to give aliases to tokens, functions or operators. This would make parsing a tougher work than necessary. So, for instance, this translates to my view that requiring a single conceptual "comma" for function arguments rather than accomodating "comma" or "semi-colon". This might be in the extension or "optional" part, but I'm also hoping to see a variable system that allows great flexibility in referencing (addressing) them. My imagined OpenFormula spec might define conceptually that these variables are conceptually all real numbers, with some stated normative conversions (e.g. strings, integers, truncation of extraneous precision floats, etc), and others left for individual implementations to convert the values on their own to match the conceptual requirement of this spec. The "great flexibility" I am thinking of would include use of URLs and web-services to query for values. Simple HTTP URL references might treat the entire response text as a string, while web-services protocol might be started off with a simplistic supplement in the OpenFormula spec to query a port for value. This needs further discussion, but the idea is allow the entire web-service space to be part of the formula-referenceable domain. Best Regards, Chin Chee-Kai SoftML Tel: +65-6820-2979 Fax: +65-6743-7875 Email: cheekai@SoftML.Net http://SoftML.Net/ On Tue, 8 Feb 2005, David A. Wheeler wrote: >>Gary Edwards wrote: >>> Hi David, >>> >>> Thanks for the concerned comments and all the considerable effort you >>> have put into solving this problem. You're challenging us all to go >>> where none have dared tread before. So go ahead and lead the way. >>... >>> Your kindness in the way you're approaching this issue is much >>> appreciated, and i personally like your proposal for a separate >>> standalone "OpenFormula" specification. It may be a good way to break >>> through the logistics of the current specification situation, while >>> allowing room for the continued push to develop a truly universal file >>> format that covers the ever evolving needs of a rapidly expanding >>> productivity environment. >> >>Great! I'm glad you like my proposal for a separate document. >>It sounds to me like that would be the best way to move forward. >>That way, working on a lengthier specifications for formulas >>won't hold up progress on the whole Open Document specification. >>Especially since formula specification is a clearly separable area. >> >>I'm currently working through to create a first draft >>of this stand-alone document, and hope to post a first draft >>in a few days. I'll base it on the docs I posted before. >> >>Here are my current thoughts... I'd REALLY appreciate any >>comments about them: >>* I'd like to unify all the different places formulas appear, >> e.g., tables/spreadsheets, text:formula, draw, animation. >> Having a single consistent formula syntax would help the >> user experience, and it's easier to implement too. >>* To do that, I think I need to define something I'll call >> "context", which is the environment given to the formula. >> If a formula has a bare variable such as in >> "=mystuff+3", there needs to be a way to find "mystuff". >> The answer: the formula looks for that in the current >> "context". So this means that draw'ing would have >> a different context than text (text would have a context >> that included page number values, etc.). In a spreadsheet, >> bare variables include named ranges. The context >> also identifies the current table; if there's >> no current table, then any reference to the current >> table will fail. >>* To do that, I also MUST include definitions for the >> functions required in the specification for draw:formula >> such as sin(), cos(), etc. Eventually a large number >> of predefined functions need to be defined, though not >> necessarily in this specification.. there might even be >> another supplemental document defining more functions. >>* Some formulas use "<>" (like spreadsheets), >> some use "!=" (like draw:). The simplest solution is to >> require all readers to read both; then it just doesn't matter, >> and I don't see a problem with accepting both. >> OOo currently uses <> in spreadsheets, but "!=" has the >> advantage of being easier to read in the XML >> because "!=" doesn't require any character escapes. >>* If formulas begin with a letter, then the following letters >> must be followed by a colon and that gives the namespace >> for that formula. If the formula begins with "=", then >> the formula is provided in a special default namespace >> usually given the prefix "formula:" (which you can also >> specifically provide)... and the following text must >> meet the OpenFormula specification. >> >> >>> I'm even wondering if this isn't something >>> that should be tossed back to the OOo Community as a project? >> >>I've never seen a "community" create a first draft of any >>doc or program. Usually someone with an itch creates the first draft. >>If others think it shows promise, they then work to improve it. >>Hopefully, I can create something that'd work as a starting point. >> >> > One of >>> the great attributes of the OASIS OpenDocument TC is that we have armies >>> of engineers and beta testers from OOo, StarOffice, and KOffice waiting >>> to rip into the next insolvable problem, and do what has never been done >>> before :) >> >>I think the OASIS OpenDocument TC is the right >>place for this OpenFormula specification. I view it as basically >>a supplemental document, one that will require discussion among >>OOo, StarOffice, KOffice, and others.... and one that might even >>follow this process through to an OASIS vote and ISO >>(as an independent document or as an appendix). >> >>--- David A. Wheeler >> >>