Re: [office] List Proposal Vote Deadline on Wednesday

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

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