Re: [office] List Proposal Vote Deadline on Wednesday

[marbux <marbux@gmail.com>]

On 5/3/07, Michael Brauer - Sun Germany - ham02 - Hamburg
<Michael.Brauer@sun.com> wrote:
> I further believe that the "compatibility" with existing file formats
> is, if at all, only one difference between the proposals. Other
> differences exist regarding the backward compatibility with ODF 1.1, and
> regarding the separation between content and style - a requirement that
> our charter explicitly mentions.

By emphasizing what is in the existing charter's requirements, are you
hinting that the migration from binary formats to ODF without data
loss and interacting with Microsoft formats in business processes use
cases are somehow disqualified from consideration by this TC? I am
sure that governments around the world would like to know. See
<http://opendocumentfellowship.org/node/91>.

> Corner cases that seem to occur seldom enough in real life that nearly
> no one until now noticed that ODF currently does not cover them. The
> representation of ***usual*** lists is not changed by either proposal.
>

Are you suggesting that less than full fidelity conversions of data to
ODF are acceptable to Sun so long as they are corner cases? Please
address the migration-to-ODF and business processes interaction with
Microsoft formats use cases.

> This means, while there are differences between the proposals, otherwise
> we won't have two of them, we in my opinion must be very careful to ***not
> over-evaluate the impact they have. On "compatibility",*** but also other
> aspects of ODF.
>

Again, are you suggesting that lossy conversions of data between ODF
apps and MS Office are  acceptable to Sun? Please address the
migration-to-ODF and business processes interaction with Microsoft
formats use cases.

> To be honest, I can't follow this. Some ODF 1.1 implementations already
> have Microsoft Word filters and support the roundtrip of lists.

Please elaborate in the context of those implementations' known lossy
conversions and the migration-to-ODF apps and business processes
interactions with Microsoft formats use cases.

> As said
> above, the modifications both proposal makes to lists are minor ones and
> the representation of ***usual*** lists is not changed by either proposal.
> Because of that, I can't see how either proposal can ***largely*** change the
> situation
>

So lossiness in any lists other than "the representation of usual
lists" is acceptable to Sun? Again, please discuss your employer's
position in regard to the acceptable degree of lossiness in the
migration-to-ODF apps and business processes interaction with
MIcrosoft formats use cases.

> > Let me also state for the record my that primary concern with the list
> > proposals has nothing to do with the "compatibility with existing file
> > formats - round trip" issue - important as that might be to internal
> > plugin converters and translators.

Thank you for being candid about your priorities.  As someone who
spends most of every waking day duking it out with Microsoft in the
trenches of public opinion about ODF and MOOXML, I ask that Sun
re-examine its priorities in light of the migration-to-ODF apps and
business processes use cases. You might consider seeking input from
the City of Munich. I understand that it cost them over $3,000 per
seat to migrate their business processes to Sun's ODF products,
largely because of the interop barrier with MS Office legacy formats.
Is that acceptable to Sun?

>
> Can you explain which of the two proposals in your opinion adds an
> application specific implementations method to ODF? Lists in ODF are
> based on HTML lists. That's the case for both proposals.

I have previously pointed out that neither Sun nor KOffice currently
implement true outliners in their ODF apps. I am far from convinced
that HTML lists are an appropriate model for outliners and because of
that fact WordPerfect should be the reference application for lists.
At bare minimum, there should be at least one developer of a true
outliner involved if we are going to redesign lists. Otherwise, we are
flying blind and fairly invite having to redo the relevant portions of
the specification for a later version of ODF. We simply do not know
whether either list proposal will work for true outliners. Or is it
that Sun would prefer that ODF not offer other developers' users any
advanced features Sun does not implement itself?

> However, as I said above: We are talking about corner cases. Anything we
> discuss regarding lists does not effect the ***usual*** lists we find in
> documents. So we really ***must not over-evaluate*** the differences.
>
Again, you seem to be suggesting that a degree of lossiness in data
conversions is acceptable to Sun. Please rexamine Sun's position in
light of the migration-to-ODF and business processes interactions with
Microsoft formats use cases.

> The ballot has closed now. This means, the ODF 1.2
> specification will contain some clarifications for lists and will add
> some new capabilities for lists and for numbered paragraphs. That's in
> my point of view far more important than the questions whether this is
> achieved by proposal (A) or (B).
>

Please be advised that if the interoperability with MS Office issue is
not definitively resolved soon, whether by technical resolution or by
a prompt commitment not to release ODF 1.2 from the TC without any
necessary fix, I will be doing my level best to raise resistance to
ODF 1.2 as contemplated by yesterday's vote. As it stands, you have
left an unmistakable record that lossy conversions between MS Office
formats and ODF  is an acceptable situation for Sun. I doubt that many
of your large customers will agree and I intend to tell the world of
Sun's position unless this interoperability issue is resolved briskly.
See e.g., E-SIGN Act, 15 U.S.C. 7001(d)(1)(B) (electronically
preserved records must "accurately reflect[] the information set forth
in the contract or other record" and be "in a form that is capable of
being accurately reproduced for later reference, whether by
transmission, printing, or otherwise"); Sarbanes-Oxley Act, 15 U.S.C.
7261(b) (financial information must "not contain an untrue statement
of a material fact").

Would you suggest that Sun's customers simply ignore the law and if
so, are you ok with imposing that decision on other developers who are
considering adding ODF support to their apps?

Best regards,

Marbux