[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]