[OASIS Issue Tracker] (OFFICE-4135) investigation of suitability of OpenFormula for word processors

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/OFFICE-4135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Stahl updated OFFICE-4135:
----------------------------------
    Component/s:     (was: Part (Formula))

> investigation of suitability of OpenFormula for word processors
> ---------------------------------------------------------------
>
>                 Key: OFFICE-4135
>                 URL: https://issues.oasis-open.org/browse/OFFICE-4135
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Task
>          Components: Conformance, Fields, OpenFormula, Part (Schema), Part 4 (Formula) [1.2: 2], Table, Text
>    Affects Versions: ODF 1.3
>            Reporter: Michael Stahl
>            Priority: Minor
>
> i've tried to investigate what kind of (non-standard) formulas are currently implemented in Writer, and whether OpenFormula 1.3 would be suitable for word processors.
> there are many open questions here that could benefit from comments by someone with OpenFormula experience, marked with "Q:".
>  AFAIK, OpenFormula has never been used in a word processor.
>  * documentation of existing formula support:
>  ** Writer: [https://help.libreoffice.org/7.4/en-US/text/swriter/02/14020000.html?DbPAR=WRITER]
>  ** Word:
>  *** [https://support.microsoft.com/en-us/office/use-a-formula-in-a-word-or-outlook-table-cbd0596e-ea8a-485e-a35d-b2cb2c4f3e27]
>  *** OOXML 17.16.3 Formulas and expressions
>  * formulas may occur on:
>  ** style:condition "is-true-formula" - not implemented
>  ** table:condition - content validation not implemented
>  ** table:expression - named expressions not implemented
>  ** table:formula - table cells
>  ** text:formula - fields
>  * potential issues for Writer:
>  ** sub tables (table:sub-table) - there is notation for nested cells
>  ("SheetLocator"), so should be representable
>  ** nested tables - every table may have a name (table:name), so this can
>  be used as the SheetName in OF expressions
>  ** built-in variables: there's a bunch of them:
>  E (Euler's - missing in OF?), 7 document statistics ones,
>  15 undocumented user-data ones "user_firstname" etc.
>  *** Q: do we need to add these?
>  ** formulas may refer to variables by name
>  *** type "variableName" = "string"
>  *** variables defined in 7.4.2 <text:variable-decls>, 7.4.7 <text:user-field-decls>
>  *** representable via quoting:
>  SimpleNamedExpression ::= Identifier | '$$' (Identifier | SingleQuoted)
>  *** these must be interpreted as 5.11 "Named Expressions"
>  **** currently there is an obvious association with
>  9.4.11 <table:named-expressions>
>  table:named-expression / table:named-range
>  **** Q: unclear if associating NE with variable-decl requires
>  changes to the text?
>  **** Q: unclear if requirement for case-insensitive names is an issue
>  **** evaluation must produce the *current* value of the variable
>  (the same variable may be set to different values by multiple
>  fields; evaluation depends on the position of the
>  formula-carrying element relative to the set field)
>  ** formulas may refer to database addresses
>  *** string that contains DB name, table name, column name
>  (dot-separated), may be quoted with []
>  *** also representable via quoting
>  *** current row is selected by database fields
>  7.6.4 <text:database-next>
>  *** mostly the same concerns apply, except additionally:
>  **** Q: there is no declaration for these in the document like variable-decl?
>  is there a requirement that every NE must be declared?
>  ** evaluation of name: try if name is a builtin or defined variable, otherwise try database
>  Q: is this acceptable?
>  ** evaluation of field formulas may result in these types:
>  bool, long, double, string, (error)
>  ** evaluation of cell formulas may result in these types:
>  double, (error)
>  ** cell evaluation to numeric value: if it doesn't contain a formula or
>  value, and starts with a field (preceded by whitespace) (one of which
>  is 7.7.14 <text:table-formula> (deprecated)), the cell value is the
>  field value, otherwise text parsed with number format
>  ** horizontally merged cells are addressed differently than in Calc:
>  merge A1+B1, next cell in Writer/Word is B1, in Calc is C1
>  Q: need to add a distinction text document vs. spreadsheet for
>  merged cells in 9.2.1 Referencing Table Cells?
>  * conformance:
>  ** part4 2.3.1 B) "It shall conform to one of: (C16) OpenDocument Formula
>  Small Group Evaluator, (C17) OpenDocument Formula Medium Group
>  Evaluator or (C18) OpenDocument Formula Large Group Evaluator"
>  *** neither of these look suitable for text documents; maybe need to
>  specify another one
>  ** Q: is this required by the part2 conformance?
>  *** it only requires syntactic conformance of formulas? there isn't
>  an actual requirement of an evaluator conformant with part4?
>  * 3.4 Host-Defined Behaviors
>  ** Q: not sure what this implies - is it effectively just documentation?



--
This message was sent by Atlassian Jira
(v8.3.3#803004)