Re: [office] List Proposal Vote Deadline on Wednesday

[marbux <marbux@gmail.com>]

Bravo, Michael! A message completely devoid of any reference to any
specific statement I made. You've managed to create a study in the art
of generalized avoidance of any actual communication of information.
My heartiest congratulations. (But do work on getting your word count
down.)

Best regards,

Marbux

On 5/4/07, Michael Brauer - Sun Germany - ham02 - Hamburg
<Michael.Brauer@sun.com> wrote:
> Marbux,
>
> you are unfortunately mis-interpreting what I have said. What I did say
> was that my own vote was influenced by the question of backward
> compatibility and a separation of content and style. I further explained
> why I believe that the differences between the two proposals regarding
> interoperability are not as large as they may appear, and why I don't
> think that either proposal is, as Gary said, "a killer for plug-ins".
>
> I did not say anything about Sun's position regarding Microsoft Office
> interop, and it is therefore entirely unclear to me how you can derive
> what you say below and in the other mails regarding this topic from that.
>
> I only want to state here that what you say about our position, is not
> our position, and that you are quoting and interpreting me incorrectly.
>
> I further would like to refer you to Oliver Wittmann's
> posting from yesterday, and would like to invite you to read the blog of
> Sun's OpenOffice.org developers where you can find a lot of information
> about our work on interoperability with Microsoft Office:
>
> http://blogs.sun.com/GullFOSS
>
> Best regards
>
> Michael
>
> marbux wrote:
> > 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
>
>
> --
> Michael Brauer, Technical Architect Software Engineering
> StarOffice/OpenOffice.org
> Sun Microsystems GmbH             Nagelsweg 55
> D-20097 Hamburg, Germany          michael.brauer@sun.com
> http://sun.com/staroffice         +49 40 23646 500
> http://blogs.sun.com/GullFOSS
>
> Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
>            D-85551 Kirchheim-Heimstetten
> Amtsgericht Muenchen: HRB 161028
> Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
> Vorsitzender des Aufsichtsrates: Martin Haering
>
>