Re: [oic-comment] State of ODF Interoperability ? Draft Rev 0.2 -- Discussion of interoperability

[marbux <marbux@gmail.com>]

On Tue, Jun 9, 2009 at 8:07 AM, <robert_weir@us.ibm.com> wrote:
> marbux <marbux@gmail.com> wrote on 06/09/2009 12:13:33 AM:

> ISO/IEC 2382 is the International Standard for IT Vocabulary.  So to say
> that its use is inapplicable to international standards is absurd.

That's a straw man argument. I said its definition of interoperability
was "inapplicable to international IT standards," not to all
international standards.

> Not
> only is it permissible, the use of this vocabulary standard is
> specifically recommended in ISO Directives Part 2 "Rules for the structure
> and drafting of International Standards".

ISO/IEC JTC 1 Directives provide in section 1.1:

 "Where differences between this document and the ISO/IEC Directives
exist, the provisions of this document shall govern."

<http://www.jtc1sc34.org/repository/0856rev.pdf>, pg. 11.

A relevant difference exists between ISO/IEC Directives Part 2's
incorporation by reference of ISO/IEC:2382 (generally applicable to
international standards of all types) and JTC 1 Directives; the
latter's Annex I provides the definition of "interoperability"
specific to information technology international standards.

The ISO/IEC decision that the JTC 1 Directives take precedence when
there is a conflict between that volume and ISO/IEC Directives does no
more than restate the common rule of interpretation that more specific
requirements take precedence over the more general. See e.g.,  Simpson
v. United States, 435 U.S. 6, 15 (1978),
<http://supreme.justia.com/us/435/6/case.html> ("Finally, our result
is supported by the principle that gives precedence to the terms of
the more specific statute where a general statute and a specific
statute speak to the same concern, even if the general provision was
enacted later.")

JTC 1 Directives are specific to IT international standards. ISO/IEC
Directives are the more general, applying by default to all
international standards of a technical nature. Because there is a
conflict, the more specific JTC 1 Directives definition governs, as is
straightforwardly stated at page 11 and quoted above.

> This is a policy document, not a standard for IT vocabulary. The section
> you quote is in annex to that policy document. You have conveniently
> omitted that the sentence you quote begins "For the purpose of this policy
> statement, interoperability is understood..." which makes it clear that
> the definition is scoped to that specific policy statement, and is not
> being set out as a general definition.

May I suggest that you spend some time pondering the definition of
"annex" and reconcile that meaning with the statement on JTC 1
Directives pg. 11 that:

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

The distinction you perceive does not exist if one consults the
dictionary and heeds the last-quoted sentence.

> HTML is from authoring tool to reading tool.  Although the connection is
> mediated by emailing the HTML or posting to a web server rather than
> direct tool-to-tool communications, the exact same thing is true of word
> processors.  My word processor does not communicate directly with yours. I
> need to save the document, send it via email, save it in a document
> repository, post it on the web, etc. So this is directly analogous to
> HTML. Remember, there are word processors that save their documents in
> HTML format and there are WYSIWYG HTML authoring environments that are
> indistinguishable from word processors.  So I don't think you can make an
> argument that interoperability of HTML and documents are entirely
> different things.

That is irrelevant to the paragraph of the draft document under
discussion, which discusses HTML in the context of web browsers as its
only example of  "interoperability." Moreover, the general inability
of HTML authoring agents to interoperate is well beyond legendary. The
most popular work-around I'm aware of is the XML/RPC protocol, which
is ordinarily used only to exchange data between different instances
of the same application, not between different IT systems.

One need look no further than the W3C Compound Document by Reference
Framework to see several types of interoperability conformity
requirements missing from HTML (and ODF).
<http://www.w3.org/TR/2007/CR-CDR-20070718/#conformance>.

> JTC1 covers everything from network protocols to optical disc formats to
> programming languages to character sets.  I think you are stretching
> things too far to read JTC1's policy statement on interoperability in such
> a narrow sense that it applies only for document formats and not for the
> other 99.9% of ISO/IEC standards.

That's your straw man, not what I said. What I did say is that JTC 1
Directives apply to "IT international standards." I suppose I might
have qualified that further to limit it to IT international standards
that are processed by JTC 1. But however you cut it, JTC 1 Directives
apply to ISO/IEC:26300 OpenDocument Formats. Indeed, I recall
occasions where you cited them yourself in regard to discussion of
OOXML's adoption.

Remember, when the JTC1 policy
> statement was written, there were no ISO standards for office document
> formats.  You need to read it in a way that it would have make sense at
> the time it was written.

I need to read it in a way that it would make sense when last adopted,
on 5 April 2007. There is no persuasive argument that the Annex
containing the interoperability provisions does not apply to
ISO/IEC:26300. Shortly before the current version of JTC 1 Directives
was adopted, SC 34 sought an exemption from JTC 1 SWG Directives for
ODF:

"There are no mechanisms by which National Bodies can validate that
organizations claiming conformance to the JTC1 standards are actually
conforming. SC34 feels that it should be a requirement for all PAS and
fast-track submitters to provide National Bodies with conformance
procedures. Where standards, such as DIS 26300 [OpenDocument], only
require conformance to parts of the standard, there should be clearly
documented boundaries, at a high level in the document structure, to
which conformance can be claimed.

"Response: They felt that there was no way to accomodate [sic] this proposal."

Keld Jørn Simonsen, Delegate report from JTC 1 SWG directives meeting
- March 7-9, 2007, ISO/IEC JTC 1/SC 34 N0835 (March 22, 2007), section
7, <http://www1.y12.doe.gov/capabilities/sgml/SC34/document/0835.htm>.

Less than a month later JTC 1 Directives v. 3.0 was issued with the
definition of "interoperability" intact along with the requirement
that:

"Standards designed to facilitate interoperability need to specify
clearly and unambiguously the conformity requirements that are
essential to achieve the interoperability."

SWG Directives --- the JTC 1 working group responsible for drafting
and maintaining JTC 1 Directives --- was specifically asked to create
an exception to that rule in JTC 1 Directives for ODF and just as
specifically declined to do so.

It was a legally sound decision. Under the Agreement on Technical
Barriers to Trade,
<http://www.wto.org/english/docs_e/legal_e/17-tbt_e.htm#articleII>:

"2.2  Members shall ensure that technical regulations [and hence
international standards] are not prepared, adopted or applied with a
view to or with the effect of creating unnecessary obstacles to
international trade.  For this purpose, technical regulations shall
not be more trade-restrictive than necessary to fulfil a legitimate
objective, taking account of the risks non-fulfilment would create.
Such legitimate objectives are, inter alia:  national security
requirements;  the prevention of deceptive practices;  protection of
human health or safety, animal or plant life or health, or the
environment. ..."

This is no more than a restatement of antitrust law governing
standards work in industry consortia such as OASIS, but projected to
encompass the work of national standards body representatives working
in bodies such as JTC 1. So it should come as no surprise that the
same requirement extends to all technical standarization activities,
whether private or goverrnmental, throughout the territories of member
nations. Agreement, supra, Annex 3:

"E. The standardizing body shall ensure that standards are not
prepared, adopted or applied with a view to, or with the effect of,
creating unnecessary obstacles to international trade."

See also Agreement, Article IV:

4.1 Members ... shall take such reasonable measures as may be
available to them to ensure that local government and
*non-governmental* standardizing bodies within their territories, as
well as regional standardizing bodies of which they or one or more
bodies within their territories are members, accept and comply with
this Code of Good Practice. ... The obligations of Members with
respect to compliance of standardizing bodies with the provisions of
the Code of Good Practice shall apply irrespective of whether or not a
standardizing body has accepted the Code of Good Practice."

One must therefore ask whether the ODF lack of specification of
conformity requirements that are essential to achieve interoperability
has "the effect of, creating unnecessary obstacles to international
trade." In this case, we have the word of Rob Weir that *not*
specifying interoperability conformity requirements in a standard that
are essential to achieve interoperability is *not* the most efficient
way to achieve interoperability:

"[I]nteroperability is most efficiently achieved by conformance to an
open standard where the standard clearly states those requirements
which must be met to achieve interoperability."

Rob Weir, A Follow-up on Excel 2007 SP2's ODF Support, An Antic
Disposition (7 May 2009),
<http://www.robweir.com/blog/2009/05/follow-up-on-excel-2007-sp2s-odf.html>.

I agree with what you said in the passage just quoted. The only
mystery is why you believe that ODF should not contain such a
specification, a topic you did not address in your quoted article or
anywhere else that I know of. There is a good reason that this is a
minimum requirement for all JTC 1 international standards: the
relevant lack of specificity creates unnecessary obstacles to market
entry by competitors, i,e., "unnecessary obstacles to international
trade" in the parlance of the Agreement on Technical Barriers to
Trade.

So why is it necessary to leave blank in ODF the conformity
requirements that are essential to achieve the interoperability? Try
as I might, I cannot fit ODF into the Agreement's listed exceptions
for "national security requirements;  the prevention of deceptive
practices;  protection of human health or safety, animal or plant life
or health, or the environment." What is *your* justification for
keeping the spec dark and mysterious to implement? What TC agenda item
do you believe to be more important than specifying the ODF conformity
requirements that are essential to achieve interoperability?

Cf., European Committee for Interoperable Systems, "Open Document
Formats As An Enabler of Interoperability: Comparison of the Oasis
Opendocument Format and Microsoft Office Open XML" (undated but file
stamped July 2, 2007), pg. 2, formerly available at
<http://www.ecis.eu/inter/documents/ECIS_ODF_OOXML_comparison.pdf>
and at <http://osacademy.hosting.amaze.nl:8060/repository/resources/white-papers/ecis_paper_on_odf_ooxml_final.pdf/view>:

"The merits of ODF have already been established by its wide industry
adoption. As noted above, numerous PPA vendors have implemented
support for it in their products both on Windows and on other
operating systems. Such widespread adoption is only possible because
ODF is *fully disclosed and created to allow for document
interoperability* by making it easy for various applications to
*exchange* documents with full fidelity, i.e., without any loss of
data or formatting of the document."

These are not abstract issues. They are vitally important to software
users. See e.g., Bob Sutor, Interoperability and Substitutability (5
September 2006), <http://www.sutor.com/newsite/blog-open/?p=1041>:

"One of the benefits of interoperability is substitutability: the
ability to take one software application from one provider and put in
its place another application from a possibly different provider. Open
standards enable interoperability and hence substitutability.

"... Anything that locks me into software from a single provider is a
strong negative.

...

"There is another question that I would have that I would try to get
answered, even though it might be an unusual query to pose to a
salesperson or evangelist. That question is: 'What are the features
and characteristics of your software that will let me rip it out and
replace it with software from another provider in 6 months, a year, 3
years?' Ouch.

"Try putting that into an internal product plan: list of features that
let users switch to software from other providers, possibly open
source. Have you done that? ... If you provide an ODF-compliant
application you have. Providers of software that implement open and
non-vendor controlled standards are used to living with the higher
level of risk that substitutability engenders. ..."

Is this not the TC charged with responsibility to make such ODF
interoperability myths come true? Why do you battle against the JTC 1
Directives requirement that this TC do so? "[F]ully disclosed and
created to allow for document interoperability?" I ask in response:
"What are the features and characteristics of your software that will
let me rip it out and replace it with software from another provider
in 6 months, a year, 3 years?" Specifying in ODF "clearly and
unambiguously the conformity requirements that are essential to
achieve the interoperability" would be a good start, yes?

> Remember, HTML is also an ISO standard (ISO/IEC 15445:2000).  Do you
> believe that it is not a "lawful international standard" because it was
> "not even designed for interoperability" (by your definition)?

Yes.  And it is unmistakably HTML's most tragic limitation. The globe
is brim full of HTML authoring agents that can't talk to each other.
Whatever one might say about the beneficial effects of HTML pale in
comparison to what could have been achieved were it actually designed
for interoperability as the law requires. It's a "standard" with no
thought given to 2-way conversations. It's cut from the paradigm of
transmission ---> reception, rather like AM radio. AM radio may be
fine for listening to music, but if you want to get some work done
with someone else, you pick up the telephone or fire up your eMail
client so you can have a 2-way conversation.

> Could you point me to a handful of relevant international standards which
> you believe are interoperable and lawful by your reading of the applicable
> rules and definitions?

Irrelevant. We are here interested in what the applicable rules are,
not in how how popular the rules are or how often they have been
honored or dishonored.

Changing the subject is not a favored technique in formal debate.
Doing so is generally regarded as a logical fallacy because it evades
rather than addresses the merits of the opponent's argument. You have
not addressed my central point that "interoperability" means 2-way
rather than 1-way exchange of data and mutual use of the data at both
ends of the round trip, according to JTC 1 Directives, to the European
Community Court of First Instance, to the WTO Appellate Body, and to
prior statements by IBM, Sun, and Microsoft spokespersons. I'll throw
in another IBM statement to make the point even more clear:

"Interoperability is the ability for two different and independent
software applications to *exchange* information without loss of data,
semantics, or metadata."

Bob Sutor, Interoperability More or Less, Bob Sutor's Website and Blog
(25 January 2007), <http://www.sutor.com/newsite/blog-open/?p=1372>.

Your position is the outlier here, not mine. IBM seemed to have no
confusion about the meaning of "interoperability" when arguing against
OOXML adoption because of function duplicative of ODF's and
insufficient disclosure of interoperability conformity requirements.
And somehow, I doubt that IBM through ECIS is currently arguing to DG
Competition that the ISO/IEC:2382 definition of "interoperability"
applies to OOXML and the specs for the Office binary formats, rather
than what the Court of First Instance said the term means.

But rather than addressing the weight of the authorities I cited or my
explanations that accompanied them, you chose to ignore all but the
JTC 1 Directives definition, then mount an attack on it in isolation,
and in a manner that did not address whether "interoperability" has a
1-way or 2-way meaning.

So I put the question to you directly: Are you advocating for a 1-way
definition of "interoperability" for ODF or for leaving that point
ambiguous in the TC's report on the state of ODF interoperability?
And if not, why are you wasting your time and mine with arguments
against an unambiguous 2-way definition  of the term in this TC's
report on The State of ODF Interoperability?

Best regards,

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

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