OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [office] List Proposal Vote Deadline on Wednesday


Sorry, just realized I sent this to Bruce and not to the list as I intended.

---------- Forwarded message ----------
From: marbux <marbux@gmail.com>
Date: May 2, 2007 6:09 PM
Subject: Re: [office] List Proposal Vote Deadline on Wednesday
To: Bruce D'Arcus <bdarcus@gmail.com>


On 5/2/07, Bruce D'Arcus <bdarcus@gmail.com> wrote:
> Paul,
>
> On May 2, 2007, at 4:53 PM, marbux wrote:
>
> > Not trying to be difficult here. I'm just really concerned about
> > interoperability with MS Office. It matters whether ODF is just a
> > format for Sun and KOffice or is for everyone to use.
>
> I think you need to be really careful with the (public) language here.
> Isn't this exactly the kind of thing MS marketing people will love to
> quote? MS is on the side of "everyone" and Sun/KOffice is some kind of
> cabal?
>

I am far less concerned by what Microsoft might say than I am with
what happens on this TC. Microsoft's flacks will find a way to bad
mouth ODF regardless. And I am not saying that Sun and KOffice are
some sort of cabal, only suggesting that we need to avoid even
inadvertently building interoperability barriers into the
specification. We don't need to address whether it is done
intentionally; we need to address whether the list proposal adopted
today does in fact create an ODF interoperability barrier with MS
Office.  If so, then I'm not going to stand by silently watching while
that goes down.

> I've never been convinced by Florian and Gary's technical argument. I
> think Florian's proposal essentially reproduced bad design/behavior in
> Word in ways that would compromise the future integrity of ODF.
>
> I'm not sure I'm right about that, but how would it change this
> discussion if I am right?
>

I am clueless as to what you mean by the "future integrity of ODF."
But I do know there are a host of government bodies and businesses out
there who need to get from point A (vendor lockin file formats) to
point B (ODF apps) without data loss.  I'm told it took the City of
Munich over $3,000 per seat to get there even with a lossy migration.
If we can't quickly get that cost way, way down and the conversion
fidelity way, way up, the future integrity of ODF will only matter to
the few historians still studying our obsoleted file formats.

I also know that there is exactly one development team on this entire
planet that is attempting to provide the means of full fidelity
conversions from Microsoft formats to ODF. And I know that team has
been saying for months that they can't pull it off if the Sun/KOffice
proposal is adopted without modification to accommodate for their
issues.

If anyone else was even trying to accomplish full fidelity
round-tripping of documents with MS Office and that someone else said
there was a way to work past the Sun-KOffice proposal, I'd be more
inclined to doubt what Gary and Florian have been saying. Frankly, I'd
also be more inclined to doubt them if I had seen any indication that
others on the TC were even concerned about full fidelity interop with
MS Office. But instead, I keep running into this wall of silence when
someone raises the use case of the fully automated business process,
where the market requirement is unquestionably *full fidelity* format
conversions.

There is no doubt about the degree of interoperability with ODF apps
Microsoft wants. See "Ballmer Invites Patent Talks with Competing
Linux Vendors" <http://www.eweek.com/article2/0,1895,2050848,00.asp?kc=EWEWEMNL103006EP17A>
("Nor will the collaboration team attempt to build file converters
that can make files 100 percent compatible between the two file
formats, he said. But it will achieve the level of interoperability
that customers can work with, he said." In other words, just good
enough to be able to argue that interoperability is not an issue.

But at the same time, we know that Microsoft paints full fidelity
conversions from legacy formats to XML as a mission critical market
requirement. See e.g., white paper accompanying Ecma 376's submission
to JTC-1, <http://www.ecma-international.org/news/TC45_current_work/OpenXML%20White%20Paper.pdf>
("The emergence of these four forces ... created an imperative to
define an open XML format and migrate the billions of documents to it
***with as little loss as possible").***

Microsoft has certainly not been bashful about discussing the business
process use case. See e.g., id. ("markets have diversified to include
a new range of applications not originally contemplated in the simple
world of document editing programs. These new applications include
ones that: * generate documents automatically from business data; *
extract business data from documents and feed those data into business
applications; * perform restricted tasks that operate on a small
subset of a document, yet preserve editability").

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; and [ii] if not, is that how a majority of the voting TC
members want things to be?

In that regard, I propose the following changes in the TC charter.

Presently, the OASIS OpenDocument Technical Committee's charter,
<http://www.oasis-open.org/committees/office/charter.php>, contains
the following statement of purpose:

>>>

Statement of Purpose

The purpose of this TC is to create an open, XML-based file format
specification for office applications.

The resulting file format must meet the following requirements:

   1. it must be suitable for office documents containing text,
spreadsheets, charts, and graphical documents,
   2. it must be compatible with the W3C Extensible Markup Language
(XML) v1.0 and W3C Namespaces in XML v1.0 specifications,
   3. it must retain high-level information suitable for editing the document,
   4. it must be friendly to transformations using XSLT or similar
XML-based languages or tools,
   5. it should keep the document's content and layout information
separate such that they can be processed independently of each other,
and
   6. it should 'borrow' from similar, existing standards wherever
possible and permitted.

<<<

I propose that we move requirement 4 to the end of the list, renumber
the requirements accordingly, and add a new requirement 7 so the
section reads:

>>>

Statement of Purpose

The purpose of this TC is to create an open, XML-based file format
specification for office applications.

The resulting file format must meet the following requirements:

   1. it must be suitable for office documents containing text,
spreadsheets, charts, and graphical documents,
   2. it must be compatible with the W3C Extensible Markup Language
(XML) v1.0 and W3C Namespaces in XML v1.0 specifications,
   3. it must retain high-level information suitable for editing the document,
   4. it should keep the document's content and layout information
separate such that they can be processed independently of each other,
   5. it should 'borrow' from similar, existing standards wherever
possible and permitted,
   6. it must be friendly to transformations using XSLT or similar
XML-based languages or tools, and
   7. it must provide all feasible functionality required to suppport
full fidelity conversions from and to existing office document binary
file formats.

<<<

I believe an up and down vote on this proposed amendment would be
highly useful to end users such as the governments that have announced
their intent to migrate to OpenDocument.

I am of course open to refinement of the proposal.

Best regards,

Marbux


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]