RE: [oic] OIC 58 on formulas

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

1. I wouldn't do anything about this in the Interoperability Profile just
yet (and it is a really good example, for me, why we can't have a single,
all-or-nothing interoperability profile).

  1.1 The ODF 1.2 OpenFormula reconciliation between Part 1 and Part 2 is
still being worked on.  I am not sure there is much you can do with ODF 1.1
because the rules on what can be used as a formula and when a prefix is
required still need tidying up, and there may be conflicts with what is
possible to add as a supplemental practice using conformant ODF 1.1
spreadsheet documents.

  1.2 Daniel's observations are very important about there being many places
beside the <table:table-cell> table:formula attribute where OpenFormula
comes up.  In particular, the availability of OpenFormula is technically not
limited at all to conforming ODF 1.2 spreadsheet documents and there is
quite a bit about the hosting of formulas in ODF 1.2 documents that remains
to have the dots connected. 

2. Now, having said that, there is probably an useful area where some
serious OIC work could begin in anticipation of ODF 1.2 and OpenFormula.  

  2.1 There is much to be done on the behavior of the hundreds of functions
that are specified in OpenFormula.  These are still being tweaked but there
is plenty to dig into safely in anticipation of OpenFormula.  

  2.2 I'm thinking of preliminary development of confirmation and
demonstration uses of the various formulas.  One goal is to establish what
implementations do now in their support for formula functions having the
same names, whatever the particular formula syntax and semantics is.  

  2.3 The "test cases" in the current OpenFormula draft are not very good
for this, since they are not revealing about what the nature of the function
is.  Cases that demonstrate something understandable are needed.  

  2.4 I am thinking of simple relationships and identities that should be
apparent (or not) on inspection of certain cases, cases that reveal actual
deviations resulting from calculation and number-representation limitations,
and handling of edge cases and cases generally though of as undefined or
out-of-bounds.

 - Dennis

PS: I must confess that I love this stuff and someone could make a career
out of this.  I seem to have way to many other things to do, as much fun as
this kind of work is for me.  (There's probably a Masters Degree in IT
thesis project or two or three in here too.)

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
Sent: Thursday, January 14, 2010 05:53
To: oic@lists.oasis-open.org
Subject: [oic] OIC 58 on formulas

Hello Daniel,


thanks for these remarks, I'll have to look into it, but we might be able to
add them to the profile
in order to smoothen the migration from ODF 1.1 to 1.2.


Best regards,

Bart

________________________________________
From: OASIS Issues Tracker [workgroup_mailer@lists.oasis-open.org]
Sent: Wednesday, January 13, 2010 7:22 PM
To: oic@lists.oasis-open.org
Subject: [oic] [OASIS Issue Tracker] Created: (OIC-58) Other elements
containing formulas

Other elements containing formulas
----------------------------------

                 Key: OIC-58
                 URL: http://tools.oasis-open.org/issues/browse/OIC-58
             Project: OASIS Open Document Format Interoperability and
Conformance (OIC) TC
          Issue Type: Improvement
          Components: ODF11-InteropProfile
    Affects Versions: Working Draft
            Reporter: Daniel Rentz


The draft mentiones the table:formula element (8.1.3). There are more
elements that are able to contain formulas and should be mentioned in a
similar way. Unfortunately, there are some insufficiencies in the current
ODF11 spec which have been fixed in the current ODF12-CD04. I am not sure
how to handle this in our draft. Following a list of these elements with
some remarks:

8.5.3 Table Cell Content Validation (the <table:condition> element)
The ODF11 spec already mentions an optional leading namespace. The equals
sign must not occur in the conditions. Note that the namespace prefix is in
front of the entire expression, not inside the conditions which contain the
formula fragments. For example:
of:cell-content-is-between(1+2,3+4)
where "1+2" and "3+4" are the formulas without namespace and equals sign.
- If namespace is omitted, OpenFormula is assumed for all formulas.

8.5.5 Named Expressions (the <table:expression> element)
The ODF11 spec does not mention a namespace prefix at all. This has been
covered by an issue for the 1.2 version and is present in the CD04 (19.637):
- Namespace prefix is optional.
- If namespace is omitted, leading equals sign is optional, and OpenFormula
is assumed.
- If namespace is present, equals sign must follow.

14.1.1 Style Condition (the <style:condition> element) used for conditional
formatting in spreadsheets
The ODF11 spec does not mention a namespace prefix at all. This has been
covered by an issue for the 1.2 version and is present in the CD04 (19.470):
- Namespace prefix is optional.
- If namespace is omitted, OpenFormula is assumed for all formulas.
- The equals sign must not occur in the conditions (see above).


--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



---------------------------------------------------------------------
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