Re: [oic] interop profile draft: formulas in ODF 1.1

[robert_weir@us.ibm.com]

Three main decisions:

1) Namespace
2) Syntax
3) Behaviors

I think we'll all agree that the profile should mandate the use of a 
namespace prefix.  In other words, the lack of a prefix altogether is 
asking for problems.

As for the other questions, it comes down to this:  If (hypothetically) 
everyone was able to support multiple syntaxes and behaviors, then surely 
everyone is able to support a single syntax and behavior.  So the 
"everyone support everything" option appears to offer no improvement in 
interoperability, but greater cost, than the option where we converge on a 
single syntax and behavior.

I don't think we want to go down the the path of defining requirements by 
reference to a particular product.  We really need a written 
specification.

And remember, namespace, syntax and behaviors are all covered in 
OpenFormula and are slated to be part of ODF 1.2.  So we have essentially 
already solved this problem, at least for implementations which will 
implement ODF 1.2.  And since there is nothing in OpenFormula that is tied 
to ODF 1.2, and it is in a separate specification, we could apply it to 
ODF 1.1, either via an interop profile, or formally in an ODF 1.1 (second 
edition).  So the easiest thing might be to do nothing in the interop 
profile for now, until OpenFormula is completed.

-Rob



From:
Hanssens Bart <Bart.Hanssens@fedict.be>
To:
"oic@lists.oasis-open.org" <oic@lists.oasis-open.org>
Date:
09/10/2009 10:00 AM
Subject:
[oic] interop profile draft: formulas in ODF 1.1



Now the big question: what do we do with formulas ?

In today's world, ODF 1.1 implementations supporting formulas are roughly 
using two different "families"
- oooc: (with or without prefix)
- msoxl:

And of course there's the upcoming OpenFormula...


So what are we going to say in the Interoperability Profile:

1) nothing at all, leaving it as it is (while it really is an interop 
issue today)
2.1) add a clause that interoperable applications SHOULD be able to read 
and understand both oooc and msoxl, and can write out one or the other ? 
2.2) ... SHALL be able ?
3) 2.1 or 2.2 with in addition OpenFormula of: 
4) only talk about SHALL / SHOULD support OpenFormula (which isn't a 
standard yet)
5) add a clause that they SHOULD support as many as possible (makes it 
worse, IMHO)

If 2.1), 2.2) or 3):

a) don't specify it any further than that (not much as improvement, but 
better than nothing, me thinks)
b) point to some (perhaps implementation specific) notes / specification 
specifying the formulas
c.1) designate a certain implementation to be the oooc: formula reference 
implementation + another implementation to be the msoxl: reference 
implementation
c.2) point to one implementation supporting both styles to be the formula 
reference implementation


Not sure if we can do c), but in reality that probably translates into
c1) OOo 3.x for oooc: - MS-Office 200x for msoxl:
c2) a 'smaller' implementation like KSpread, Gnumeric



Best regards,

Bart

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