On 8/13/07, Thomas Zander <email@example.com> wrote:
On Monday 13 August 2007 22:39:23 Bruce D'Arcus wrote:
> They are too general. What does it *really*
> mean in practice -- for ODF or any office document format -- to adopt
> the following definition?
> "For the purpose of this policy statement, interoperability is
> understood to be the ability of two or more IT systems to exchange
> information at one or more standardised interfaces and to make mutual
> use of the information that has been exchanged."
Indeed, the above quote is an empty requirement, it is reached by any and
all specifications that describe the expected interpretation of the
specified data. Which, well, *is* exactly what a specification is.
Well, we will find out at ISO, won't we? First with Ecma 376 and then with ODF 1.2. And I will remember to qAh, yes, "open" and "interoperable" are synonyms, aren't they, Thomas? Not. Read a bit further in the portions of the Directives I quoted;
"Standards designed to facilitate interoperability need to specify
clearly and unambiguously the *conformity requirements that are
essential to achieve the interoperability.* Complexity and **the number
of options** should be kept to a minimum and the implementability of the
standards should be demonstrable. Verification of conformity to those
standards should then give a high degree of confidence in the
interoperability of IT systems using those standards. However, the
confidence in interoperability given by conformity to one or more
standards is not always sufficient and there may be need to use an
interoperability assessment methodology in demonstrating
interoperability between two or more IT systems in practice."
Thomas, perhaps you might be so kind as to direct me to the specific portion of the specification where I might find the "conformity requirements that are essential to achieve the interoperability." Is it that option to destroy foreign elements and attributes? Is it that option to destroy metadata xml:id attributes in ODF
1.2? Or is it this option:
"There are no rules regarding the elements and
attributes that actually have to be supported by conforming
applications, except that applications should not use foreign
elements and attributes for features defined in the OpenDocument
But the Directives also offer further light on what was meant by "interoperability." E.g.,
"Accordingly JTC 1 accepts the responsibility to identify the key
interfaces and produce the key IT standards at those interfaces
(including the relevant content standards, e.g. ODA, SGML, CGM) to
facilitate practical, timely and cost-effective interoperability,
**consistent with market requirements** and current technologies."
So, for example, we can now add, inter alia, "market requirements" as another facet of the *kind* of interoperability ODF must support. Now personally, I'm of the opinion that interoperability both with non-ODF applications and among ODF applications are strong market requirements. Perhaps even you may have stopped coding long enough to notice that there is a pretty strong movement afoot to harmonize Ecma 376 with ODF. You might take a look at the British Standards Institute mirror group's wiki for Ecma 376 if that trend slipped by you. But the upshot is that there's a pretty strong market requirement for interop with Microsoft Office.
According to Carol Geyer, "[t]he membership of these companies in the OASIS OpenDocument Technical Committee actually ensures that the requirements of MS Office users are considered within OpenDocument." <
Now as a non-TC member, I don't expect Carol to be an expert on OpenDocument. But certainly the folks who are TC members know what the truth is on that issue, from the very first meeting of the TC in 2002 forward. Compare,
> ("[t]he TC agreed that transformability into potential Microsoft office XML formats could be sensible, but is not a formal requirement") with Michael Brauer's response to one of many submissions of proposed Microsoft Office interoperability features by Novell and/or the Foundation to the TC <
> .("Well, I'm very open to discuss enhancements to OpenDocument if they improve the interoperability with MS Word/OOX. But at the same time, I see no reason for deprecating existing OpenDocument features (or to discourage their use) because Word/OOX does not support them. Instead, I think they should be added to OOX/Word.") And of course we can add Mr. Brauer's repeated admissions that the ODF
1.2 list "enhancement" amendment was a trade-off between never-identified new ODF application features and interoperability. (Note that the use case for the option to destroy xml:id attributes was never identified either.)
I will also note that despite the Foundation and/or Novell having submitted specific proposals for adding Microsoft Office interoperability features to ODF at least five times, Mr. Brauer never saw fit to log any of them as action items or even as suggestions on the TC agenda.
But the situation is not without its comedic moments. despite Sun's unquestionable knowledge that the ODF specification presently does not provide the support necessary for high fidelity round trip interoperability of ODF applications with Microsoft Office, Sun advertises on its StarOffice 8 home page that it has achieved just that feat with its own MS Office plug-in. See
>. ("Microsoft Office users now can have *seamless* two-way conversion of Microsoft Office documents to and from Open Document.") It seems that Mr. Brauer does not frequently read his flagship product's home page.
I agree with the point that just quoting the word 'interoperability' is
not very useful anymore.
Certainly it is not a useful term when describing this TC's work except when observing that those who believe ODF is designed for interoperability have fallen victim to disinformation deliberately spread by those who know otherwise.
>. ("And, because the native file format for OpenOffice.org is the vendor-independent OpenDocument open standard, *interoperability* is easy, making future development and adoption more certain.")
At minimum such claims should specify if you
talk about being able to roundtrip between (different) ODF
implementations OR if you mean interoperability with external competing
It seems that Florian meant the former.
I meant both, so no such distinction was necessary.