Fw: [odf-discuss] Microsoft's implementation of ODF 1.1

[marbux]

On Mon, Jan 5, 2009 at 4:59 PM,  <robert_weir at us.ibm.com> wrote:
> odf-discuss-bounces at opendocumentfellowship.com wrote on 01/05/2009
> 04:32:17 PM:
>
>>Standards are about uniformity, not about product differentiation. ODF
>>and OOXML are not true standards precisely because do not specify all
>>characteristics of an identifiable product or group of products only
>>in mandatory "must" or "must not" terms.
>
> Hi Paul, I think the above is at the core of your argument.  So I
> understand your position perfectly, are you asserting that a standard is
> only permitted to include mandatory requirements, e.g., those expressed by
> "shall" and "shall not" in ISO practice, or "must" and "must not" in IETF
> practice?

Were it only so simple. No. But the product *characteristics* -- in
the instant case, electronic document formats -- may only be specified
in such terms. You have to distinguish between specification of
product characteristics and other aspects of a standard.

One key to understanding is the interchangeability, or
substitutability, of the products in the marketplace that is the
object of standards. E.g., a 1-pound bag of flour should weigh the
same regardless of who produces the flour. The consumer is supposed to
know what to expect when they buy "a pound" of something, regardless
of the manufacturer. So too when they acquire an app whose developers
claim to produce conforming ODF documents.

Different methods might be used to manufacture the product, but the
end product must be the same, within the limits of tolerances that are
responsive to market requirements and technical feasibility. --- Which
is a rather complicated way of saying that either the wrenches  made
by one group of companies *must* be capable of interoperating with
those bolts and nuts made by still other companies or something has
gone awry in the standard setting process for nuts, bolts, and
wrenches, or one of the above is non-conforming. :-)

At the same time, options are proper in at least three circumstances:
[i] when specifying alternative methods to achieve the same result;
[ii] when expressing tolerances; and [iii] when specifying a group of
related products. E.g., you MAY do either this or that but the result
MUST be X. The thread width MAY vary but MUST fall within the range of
Y +/- Z. You MAY implement only this subset but if you do you MUST NOT
claim conformance with the superset.

Further, are you asserting that a standard that includes even a
> single optional requirement or recommendation, e.g., a "should" or "should
> not" in ISO practice, or expresses an implementation option, e.g., "may"
> in ISO practice, is not a "real standard", or is an unlawful standard, or
> is a standard that may not be specified as a requirement for government
> procurement?

No. "Should" and "should not" are only informational; they establish
no normative requirements. Who can object to more information? And as
mentioned above there are proper roles for options.

But the only room for options in specifying product characteristics
turns on the substitutability of the products in the market. If one
conforming implementation of .ODT produces a document that can't be
fully processed by another conforming implementation, it's a broken
standard.

Another way you might look at it is that standards are supposed to
define markets where all can compete on equal terms because they are
all producing the same product. The benefit to society is that with a
more stable product, manufacturers can invest more in lowering
production costs  and thereby lowering the cost to consumers.

I think this an important point: standards are supposed to be
agreements not to compete on the basis of product differentiation, but
rather on price, quality, and customer service. See e.g., Allied Tube
& Conduit v. Indian Head, Inc., 486 U.S. 492 (1988),
<http://laws.findlaw.com/us/486/492.html>. ("Agreement on a product
standard is, after all, implicitly an agreement not to manufacture,
distribute, or purchase certain types of products.")

In reality this isn't mysterious. E.g., IBM's Jochen Friedrich recently wrote:

"... ODF has been successfully implemented by a number of vendors and
application developers. Implementations include OpenOffice; Star
Office; Google Docs & Spreadsheets; K-Office; Scribus; Abiword;
ajaxWrite; Zoho Writer; Ichitaro; IBM Lotus/Domino; IBM Workplace;
Mobile Office; Gnumeric; Neo Office; Hancom Office. In other words:
all of these applications use the same standard, ODF; all of them
produce files with the extension .odt for text documents, .ods for
spreadsheets and .odp for presentations; and these files can be
opened, read and edited by either application implementing the ODF
standard. This is interoperability at its best.

"Consequently, customers freely choose the applications based on look
and feel, functionality, cost, or other criteria, without worrying
about purchasing a specific, single-vendor software in order to work
with their documents. ..."

Trond Arne Undheim and Jochen Friedrich, The Momentum of Open
Standards - a Pragmatic Approach to Software Interoperability, 5
European J. ePractice, pg. 5 (31 October 2008),
<http://www.epracticejournal.eu/document/5156>.

In a similar vein, the IBM-backed ECIS used to say on its web site:

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

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

The only thing missing from those descriptions is reality. Both
describe what should be rather than what is. But if ECIS can
comprehend the importance of ODF being "fully specified," I guess the
only mystery is why you do not.

The legal requirements are not a mystery. An international standard is
lawful only if it specifies [i] all characteristics [ii] of an
identifiable product or group of products [iii] only in mandatory
"must" or "must not" terms. WTDS 135 EC - Asbestos, (World Trade
Organization Appellate Body; 12 March 2001; HTML version), ¶¶ 66-70,
<http://www.wto.org/english/tratop_e/dispu_e/cases_e/ds135_e.htm>:

"... the 'characteristics' of a product include, in our view, any
objectively definable 'features', 'qualities', 'attributes', or other
'distinguishing mark' of a product."

...

"'... compliance' with the 'product characteristics' laid down in the
'document' must be 'mandatory'. A 'technical regulation' must, in
other words, regulate the 'characteristics' of products in a binding
or compulsory fashion."
...

"'Product characteristics' may, in our view, be prescribed or imposed
with respect to products in either a positive or a negative form. That
is, the document may provide, positively, that products must possess
certain 'characteristics', or the document may require, negatively,
that products must not possess certain 'characteristics'. In both
cases, the legal result is the same: the document 'lays down' certain
binding 'characteristics' for products, in one case affirmatively, and
in the other by negative implication."

I don't know how the Appellate Panel might have been more clear on
this point. But any options specified must by law fit *under* that
criteria.

JTC 1 Directives are in accord. The Directives state:

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

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

There is no "standardised interface" in ODF. Likewise, there is no
specification of "the conformity requirements that are essential to
achieve the interoperability." And how does one reconcile that ocean
of options in ODF with the requirement of minimizing complexity and
the number of options?

I assume you do not suggest that OpenOffice.org, Lotus Symphony, and
StarOffice coders actually use "optional," "may," "should," and
"should not" as programming constructs? Do not virtually all of those
ambiguities in ODF mask hard-coded "must" and "must not" programming
decisions in the implementations? What's the big benefit to customers
in keeping ODF dark and mysterious, in preserving all those "optional"
interoperability breakpoints?

My recent conclusion on ODF 1.1, comparing my stats with Dave Pawson's:

"Juxtaposing the 227 maximum conformance requirements statistic shown
in the attached document with Pawson's report, one may divine that no
more than 227 of the 2,578 testable paragraphs he could identify are
conformance requirements, or restated, a maximum possible 8.8 per cent
of testable paragraphs state conformance requirements. The rest are
apparently mere options or recommendations."

<http://www.universal-interop-council.org/node/37>.

Not a pretty picture and the ODF and OIIC TCs doesn't seem to be doing
a thing about it. It looks to me as though the best hope for salvaging
ODF is SC 34. Is that the way IBM wants things to be?

Best regards,

Paul

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