Re: [office] List Proposal Vote Deadline on Wednesday

["David A. Wheeler" <dwheeler@dwheeler.com>]

Marbux:
> The present situation boils down to two issues: [i] can full fidelity
> interoperability with MS Office be achieved in light of the vote just
> taken;

I believe the answer is "absolutely!".  The majority-vote proposal uses 3 keys, instead of 2, but bidirection mapping should be fine:
* MS XML -> ODF is trivial, because it's trivial to map 2 keys into 3.
* ODF -> MS XML is generally easy, but in certain cases it can be more complex to map 3 into 2.  The main issue is that in certain cases the ODF->MS XML will require special handling, but  those conditions (and solution) are the same kind of special handling that Fleurian's proposal requires.

In certain cases, the accepted proposal can represent numbering systems that MS XML and Fleurian's proposal CANNOT represent at all.  Obviously, if MS XML cannot represent it, then it can't be accurately transformed, but clearly that didn't originate in .doc or MS XML anyway.  I don't think we need to apologize that ODF can do a lot of things that MS XML simply cannot.

I don't see a problem round-tripping MS XML and ODF.  However, it IS true that after round-tripping MS XML -> ODF -> MS XML the generated XML would be different.  But that's true for MS Office too, just by loading and saving, so it's not clear that's a big deal.  It might be useful to document a "suggested mapping" each way, so that round-trips would LOOK similar.  But rather few Microsoft users examine the XML directly :-), and as long as exchanging doesn't lose data you should be fine.

You propose:
>    7. it must provide all feasible functionality required to suppport
> full fidelity conversions from and to existing office document binary
> file formats.

I think many of us are working on that, but defining "full fidelity" is tricky.  MS XML doesn't have "full fidelity" in the sense of absolute page placement of all items (change printers and it'll reformat the page).  I'd change "existing" to "existing widely-used", and drop the term "binary".

Also, "all" is a little tricky.  It's quite possible to create a spreadsheet formula that depends on non-portable semantics NOT agreed on by other spreadsheets, for good reasons.  E.G., A1+5, where A1 contains the text "4", will produce 5 on many spreadsheet programs but 9 on Excel.  It is LEGAL for spreadsheet implementations to convert the text "4" to the number 4, but NOT required (due to internationalization issues, which are discussed in the formula spec); Word Perfect Quattro Pro, OpenOffice.org, IBM/Lotus 1-2-3, and probably others always convert text in another cell into 0 when a number is requested.  In such cases we make it POSSIBLE to exchange with full fidelity, but clearly document that some constructs are NOT portable.  This is no different than with C compilers; gcc accepts many constructs that are NOT legal C code, but are product-unique extensions... if you want portability, you need to stay within the set of PORTABLE constructs.

On the other hand, the we've certainly worked hard to make it POSSIBLE to exchange with extremely high fidelity.  Again, examples from the formula spec.  There are only a few cases in the formula spec where we define a function with semantics specifically DIFFERENT than Excel, and in those cases we define a way to get Excel's semantics.  The examples that come to mind are FLOOR and CEILING; in Excel, these have horrific definitions that are completely contrary to their normal mathematical meaning.  We define these functions instead with their normal meaning, and add extra parameters so that you can also get Excel's bone-headed semantics in case you need them (primarily for exchange).  If you use FLOOR and CEILING in the usual mathematical way, you can't send them to Excel because Excel doesn't actually have that functionality... but if you use the forms that Excel can handle, a 2-way exchange is trivial (though requiring some parameter twiddling).

I think many of us are working on what you MEAN by that text, but defining what we mean is difficult.

--- David A. Wheeler