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

 


Help: OASIS Mailing Lists Help | MarkMail Help

oic-comment message

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


Subject: =?UTF-8?Q?State_of_ODF_Interoperability_=E2=80=93_Draft_Rev_0=2E2_=2D=2D_D?==?UTF-8?Q?iscussion_of_interoperability?=


Regarding  State of ODF Interoperability – Draft Rev 0.2,
<http://www.oasis-open.org/committees/download.php/32194/StateOfInterop-draft-01.odt>:

@ The draft currently states:

"According to ISO/IEC 2382-01, 'Information Technology Vocabulary,
Fundamental Terms', interoperability is 'The capability to
communicate, execute programs, or transfer data among various
functional units in a manner that requires the user to have little or
no knowledge of the unique characteristics of those units'.

ISO/IEC 2382-001's definition is inapplicable to international IT
standards and its usage has led to a serious error in the subject
draft.

The definition applicable to international IT standards is provided by
ISO/IEC JTC 1 Directives, (5th Ed., v. 3.0, 5 April 2007) pg. 145,
<http://www.jtc1sc34.org/repository/0856rev.pdf>:

"[I]nteroperability 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. An
IT system is a set of IT resources providing services at one or more
interfaces."

Unlike the ISO/IEC 2382-001 definition, the JTC 1 definition is
insusceptible to a 1-way definition of "interoperability." The
"*mutual* use of the information that has been exchanged" among "two
or more IT systems" phrases defy the concept of 1-way
interoperability.

A definition of "interoperability" with no relevant differences from
the JTC 1 definition was held to require 2-way interoperability in
Commission v. Microsoft, European Community Court of First Instance
(Grand Chamber Judgment of 17 September, 2007), para. 226, 230, 421,
<http://curia.europa.eu/jurisp/cgi-bin/gettext.pl?where=&lang=en&num=79929082T19040201&doc=T&ouvert=T&seance=ARRET>
(rejecting Microsoft's argument that "interoperability" has a 1-way
rather than 2-way meaning; information technology specifications must
be disclosed with sufficient specificity to place competitors on an
"equal footing" with Microsoft's own software in regard to
interoperability; "the 12th recital to Directive 91/250 defines
interoperability as 'the ability to exchange information and mutually
to use the information which has been exchanged'").

Sun Microsystems' definition of "interoperability" also recognizes the
importance of *mutual use* of data exchanged,
<http://www.sun.com/software/standards/definition.xml>:

"Faithful implementations of the standard must interoperate.
Interoperability means the ability of a computer program to
communicate and exchange information with other computer programs and
mutually to use the information which has been exchanged. This
includes the ability to use, convert, or exchange file formats,
protocols, schemas, interface information or conventions, so as to
permit the computer program to work with other computer programs and
users in all the ways in which they are intended to function."

Likewise, IBM vice president Bob Sutor has written,
<http://www.sutor.com/newsite/blog-open/?p=2979>:

"'Interoperability'" is the real term here, meaning that two different
pieces of software can exchange information and the meaning of that
information within a larger document or process is well understood by
both. Of course, ultimately the information may move among more than
two pieces of software."

And Microsoft standards attorney David Rudin has said, <
http://standardslaw.com/wordpress/?p=17>:

"The ultimate purpose of a software standard is to enable
interoperability between different products and services. If there is
no need for interoperability, there is little if any need for a common
standard. The point of a standard is to make it possible for devices
and services from different providers *to work together.* This also
makes most standards pro-competitive since multiple parties can create
products that compete in the market for the benefit of consumers."

Particularly given that Microsoft has joined this TC and that TC
Members IBM and Sun are seeking through a complaint to the European
Commission's DG Competition to have the principles enunciated in
Commission v. Microsoft applied to specification disclosure of
Microsoft Office formats and protocols, it seems especially
inappropriate for this TC to adopt a 1-way definition of
"interoperability." See e.g., European Committee for Interoperable
Systems, What Is the New European Commission Microsoft Investigation
About? (January 2008),
<http://www.ecis.eu/news/documents/BackgrounderJanuary2008.pdf>:

"The ECIS 2006 complaint focuses once again on both bundling and
Microsoft’s refusal
to disclose technical information necessary for interoperability with
its dominant
products, but also price-tying. Products cited where one or more of these
anticompetitive practices are on-going and particularly harmful to
competition include
the Office suite, e-mail and collaboration software, and software that
powers the
internet."

The meaning of "interoperability" has been decided in court, in JTC 1
Directives, and IBM and Sun are both arguing through ECIS before DG
Competition that the definition of "interoperability" is the same now
as it was in the Commission v. Microsoft case. The author of the
subject draft document is in a poor position to argue that the
definition is otherwise.

@ Selection of an incorrect 1-way definition of "interoperability"
also led to another serious error in the draft:

"The relationship between conformance and interoperability is subtle.
 One one hand, one can have good interoperability even with
nonconformant documents.  Take HTML, for example.  A study of 2.5
million web pages found that only 0.7% of them were valid markup1.
The other 99.3% of HTML pages were not conformant.  So conformance is
clearly not necessary for interoperability.  However, web browsers
require significant additional complexity to deal robustly with the
errors in nonconformant documents.  This complexity comes at a cost,
in development resources required to write a web browser, and greater
code complexity which typically results in slower performance and
decreased stability.  So although conformance is not required for
interoperability, we observe that interoperability is most efficiently
achieved in the presence of conforming implementations."

Web pages written in HTML and web browsers have nothing to do with
"interoperability," properly defined, because their primary use is for
1-way transmission of data from servers to client-side browsers. Web
pages are not transmitted by browsers, so there is no full "*mutual*
use of the information that has been exchanged" among "two or more IT
systems."  HTML and Web browsers provide only an example of
compatibility, not interoperability.

Indeed, HTML is not even designed for interoperability.  For example,
HTML does not specify circumstances where markup must be preserved by
a receiving editor implementation during processing for a return trip
to another editor implementation.

The last-quoted paragraph also obscures the proper relationship of
conformity requirements and interoperability as laid down by JTC 1
Directives, supra, paragraphs which should be substituted instead
because they are requirements that ODF must fulfill to become a lawful
international standard:

"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.

"An assessment methodology for interoperability may include the
specification of some or all of the following: terminology, basic
concepts, requirements and guidance concerning test methods, the
appropriate depth of testing, test specification and means of testing,
and requirements and guidance concerning the operation of assessment
services and the presentation of results. In technical areas where
there is a conformity assessment methodology and an interoperability
assessment methodology, the relationship between them must be
specified."

On the mandatory nature of those requirements, see JTC 1 Directives,
supra, pg. 11:

"These Directives shall be complied with in all respects and no
deviations can be made without the consent of the Secretaries-General.

...

"A purpose of IT standardization is to ensure that products available
in the marketplace have characteristics of interoperability,
portability and cultural and linguistic adaptability. Therefore,
standards which are developed shall reflect the requirements of the
following Common Strategic Characteristics:
*Interoperability;
*Portability;
*Cultural and linguistic adaptability."

On the necessity of specifying conformity requirements essential to
achieve interoperability, see also WTDS 135 EC - Asbestos, (World
Trade Organization Appellate Body; 12 March 2001; HTML version), para.
66-70, <http://www.wto.org/english/tratop_e/dispu_e/cases_e/ds135_e.htm>
(A technical regulation (or international standard) must specify [i]
"any objectively definable 'features', 'qualities', 'attributes', or
other 'distinguishing mark'" [ii] of an identifiable product or group
of products [iii] only in mandatory "must" or "must not" terms),
reaffirmed, WTDS 231 EC - Sardines, (World Trade Organization
Appellate Body; 26 September 2002), pp. 41-51,
<http://www.wto.org/english/tratop_e/dispu_e/cases_e/ds231_e.htm>.

In summary, selection of a definition of "interoperability"
susceptible to a 1-way meaning coupled with an example format designed
for 1-way transmission of data leaves the message that this TC's goal
is 1-way "interoperability." But that ignores the "inter" prefix of
the term. The combination of the definition with the example better
describes "intraoperability" than "interoperability." See e.g., Bob
Sutor, Interoperability vs. Intraoperability: Your Open Choice (6
December 2006), <http://www.sutor.com/newsite/blog-open/?p=1260>.

Accordingly, I suggest that the applicable JTC 1 definition of
"interoperability" be used, the inappropriate HTML example be removed,
and the paragraph discussing HTML be replaced by the JTC 1 Directives
language dealing directly with the relationship between conformance
and interoperability, since that language states requirements that ODF
must fulfill.

Best regards,

Paul E. Merrell, J.D. (Marbux)

-- 
Universal Interoperability Council
<http:www.universal-interop-council.org>


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