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: Re: [office] List Proposal Vote Deadline on Wednesday

On 5/2/07, Bruce D'Arcus <bdarcus@gmail.com> wrote:
> On May 2, 2007, at 2:03 PM, Gary Edwards wrote:
> > The "problematic" difference between the two proposals will only be
> > evident when converting from the Sun/KOffice new list model back to
> > existing file formats.  Which is to say that the Sun/KOffice list
> > model is a one way conversion.  The Novell proposal is designed to
> > accommodate a two way conversion.
> For the record, my own position on the outside of this conversation
> (I did not vote) is that:
> 1) it is not in our charter to support round-trip conversion with MS
> Office files. This is not some formality, because I actually really
> like the TC charter; it seems designed to achieve the best technical
> outcome.
> 2) there was what I would call a serious breakdown in communication
> in this process such that the value or wisdom of Florian's proposal
> was not at all clear. E.g. if 1 were in our charter, I still am
> unconvinced Florian's solution was the right one to achieve that
> goal. That's not to say that it was a bad proposal or a good one;
> just that it became very, very difficult to discern signal from noise
> in this conversation.
> So I suggest whatever process led to this confusion this time around
> not be repeated in the future.
> 3) at a certain point, we need a formal -- and public -- way to
> resolve interoperability issues between OOXML and ODF. We cannot have
> people slipping in unstated requirements of this sort every time we
> entertain some enhancement. I don't know what kind of political or
> organizational work needs to be done to make this happen, but I
> suggest somebody step up and do it.

Bruce, you do have a knack for driving right to the heart of an issue. :-)

I can support the idea of some clarification of TC goals in the
charter, although I suspect we might land on opposite sides of the
interoperability-with-legacy-applications issue.

I see at least three views of the ramifications of the vote emerging,
assuming  I have correctly understood what people are saying. Gary is
saying that MS Office <> ODF Application interop has been blocked by
this vote. Thomas is saying it's still possible and David's abstention
was based on his understanding that interop can be accomplished with
either proposal. You seem to be saying it's irrelevant because interop
with legacy applications is out of bounds per the TC's charter.

I think it matters whether full fidelity interop can be achieved not
only with MS Office, but also with WordPerfect Office and other apps
that have produced documents in non-ODF file formats. Ignoring for the
moment the issue of the charter's scope, there is an undeniable market
requirement for a sane migration path from legacy formats to apps
using ODF. See the following page I maintain that tracks government
decisions to adopt ODF applications worldwide.
<http://opendocumentfellowship.org/government/precedent>. Moreover,
consider the market requirement of full fidelity file conversions in
fully automated business processes, where apps function as routers of
information rather than as end points. 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"). Neither of the
requirements created by those acts can be satisfied by ODF
applications if full fidelity file conversions are not feasible. So if
the list vote results in full fidelity conversions not being feasible,
then we have just eliminated ODF applications from the software
procurement market for the entire U.S. government, top to bottom, and
for a good part of the private sector subject to Sarbanes-Oxley. And
that is just in the U.S.

So I would heartily endorse adding a requirement to the TC's charter
that the product be compatible with full fidelity conversions from and
to non-ODF formats, as is contemplated by the foreign element and
attribute treatment given in the existing specification's section 1.5.
I thought the requirement of full fidelity conversions was pretty
clear in the existing charter's requirement 4:  "it must be friendly
to transformations using XSLT or similar XML-based languages or
tools." But apparently not clear enough to withstand a narrow
interpretation of "friendly."

In the meantime, I would like to see the issue definitively resolved
ASAP whether the Sun-KOffice list proposal does in fact block full
fidelity interoperability with MS Office. I expect that kind of
conduct by Microsoft; I do not expect it on this TC. At least one TC
member abstained from voting, acting on the belief that it does not
block interoperabilitry. Moreover, I've staked a good part of my
reputation on ODF being a good interoperability solution for end
users. If that is no longer true, I need to be issuing some public
warnings and making some rather painful public apologies for having
misled many people who trusted my judgment.

Best regards,


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