[odf-discuss] OOXML: The next step

[marbux]

On Tue, Apr 8, 2008 at 8:39 PM, <robert_weir at us.ibm.com> wrote:

>
> Well,  the ODF standard will not contain any proprietary extensions.  It
> never has.  This by definition -- anything that the ODF standard defines is
> a standard, not proprietary.
>

> The question IDABC brings up is what an application does, not what a
> standard allows.  Standards, as currently practiced, specify technical
> requirements.  They don't specify licensing or permitted uses or compliance
> testing or patents, etc.
>

The issue we were discussing -- and what I believe the ODEF conference was
very much concerned with -- was whether ODF plus  vendor-specific extensions
will be classified as conformant ODF. The market requirement is for
"Exchange Formats" and document-level interoperability.

I could repose my question as whether ODF v. 1.2 will "clearly and
unambiguously specify interoperability requirements essential to achieve the
interoperability," as required by JTC 1 Directives. As you noted in an
earlier post in this thread, you can't do interoperability if you use vendor
extensions.


> I see a standard as providing a shared vocabulary for buyers and sellers
> to express their requirements.


You are in error. This is a matter controlled by law rather than by personal
opinion. Standards are all about the substitutability of goods, weights, and
measures. A standard specifies all characteristics of a product, weight, or
measure in mandatory terms so there is uniformity. Standards are the
antithesis of product differentiation. Their very purpose is to eliminate
product differentiation.

This is not to say that a standard vocabulary could not be created for "buyers
and sellers to express their requirements." E.g., proofreaders' marks are
such a standard. See British Standard BS-5261:2 and ISO:5776.

But ODF is not that kind of a standard. According to the TC charter, ODF is
a  "standard for office document *processing and interchange**."* * * But
the world has yet to see a first committee draft of an ODF specification
designed for document "interchange," *i.e.,* interoperability. And my
experience on the TC was that virtually every interoperability initiative
was met by the spurious argument that IT standards cannot specify how to
process markup. Cf., IETF RFC 2119, which was incorporated by reference in
OASIS ODF 1.0 but was pulled by Patrick Durusau at JTC 1:

Imperatives of the type defined in this memo must be used with care and
sparingly.  In particular, they MUST only be used where it is actually
required for interoperation or to limit behavior which has potential for
causing harm (e.g., limiting retransmisssions)  For example, they must not
be used to try to impose a particular method on implementors *where the
method is not required for interoperability.*

So interoperability is a recognized exception to the custom of IT standards
not specifying application behavior.

The TC's phase 1 work on ODF, i.e., prior to release of ODF v. 1.0 was to
include "*establishing a set of 'core' elements and attributes to be
supported by all implementations."* *Ibid.* But what the world got instead
is a conformance section that states:

*There are no rules* regarding the elements and attributes that actually
have to be supported by conforming applications[.]

Some users, like IDABC will seek applications that do not extend ODF. ODF
> should provide a way of expressing the technical side of that requirement


But will that information be provided in ODF v. 1.2? The questions I posed
in my last post go directly to whether ODF v. 1.2 will fulfill that market
requirement.

It's also quite a bit more complex than just extensions, as you mentioned in
an earlier post in this thread. Users and implementors also face,
*e.g.,*the interoperability barrier of that mountain of ambiguities in
the spec
introduced by an avalanche of passive voice sentences and the shotgun blasts
of "may" and "should" permissiveness sprinkled  liberally throughout the
spec.

There is also the highly significant issue of whether documents that include
vendor-specific extensions will be allowed to identify themselves as
conformant ODF when implementations process them. What is a conformant
implementation to do when it encounters markup whose functionality is not
defined by the standard? Please consider the problem of data loss in the
interchange of documents.


> . Other users will have stricter requirements.  Maybe archivists want to
> express the requirement that all fonts be embedded and that no object
> embedding (OLE) is used, and no macros or script is used.  So, something
> similar to PDF/A.  If so, ODF should provide a conformance class to express
> that technical requirement.  And so on.


Will ODF v. 1.2 specify that conformance class?

We can do these in the standard itself, or as separate profiles.  But I
> don't think we can express a prohibition against proprietary extensions as a
> technical requirement.
>

The issue as I see it is not prohibiting proprietary extensions as a
technical requirement. It is whether ODF v. 1.2 specifies all
characteristics of a substitutable, *i.e.,* interchangeable, product. In the
example characteristic we are discussing, it is the question of whether ODF
v. 1.2 will classify vendor-specific extensions as conformant with the
standard.

By anology, should the baker who wishes to sell 13 doughnuts for the price
of 12 be permitted to claim conformance to a standard that classifies a
dozen as the quantity of 12? Or do we require him to label his packages as
something else, *e.g.,* as a "baker's dozen."

This is really fundamental and ancient stuff in the context of standards
work. *E.g.,* the Magna Carta of 1215 provides in part, translated from the
original Latin:

There shall be standard measures of wine, ale, and corn (the London
quarter), throughout the kingdom. There shall also be a standard width of
dyed cloth, russett, and haberject, namely two ells within the selvedges.
Weights are to be standardised similarly.

<http://www.fordham.edu/halsall/source/magnacarta.html>

I am asking in effect whether the ODF TC will draft Magna Carta v. 1.2 to
read:

There shall be *more or less* standard measures of wine, ale, and corn (the
London quarter *more or less),* throughout the kingdom. There shall also be
a *more or less *standard width of dyed cloth, russett, and haberject,
namely *more or less than *two ells within the selvedges. Weights are to be
standardised similarly.

Or put yet another way, will customers know what they are paying for when
they buy licenses for software whose vendors claim conformance with ODF v.
1.2?

Or put yet another way, will a valid claim of conformance with ODF v. 1.2
guarantee a software user that he or she will not be locked into the product
of a particular vendor, that she can switch to the software produced by
another conformant ODF vendor with full confidence there will be no
compatibility issues opening and editing her old ODF documents or with
opening and editing ODF documents generated by other conformant ODF
implementations?

I think I need not make a catalog of links to the many blog posts you and
Bob Sutor have published criticizing OOXML on interoperability and
implementability grounds precisely because of the vendor-specific extension
issue.

Why is this any less evil if it is the ODF standard that exhibits the same
defects? For over 30 years, the only choice I have had as a word processor
user is which vendors' product I choose to be locked into. Standards are
supposed to be about freeing me from that kind of lock-in.

Or try it this way: Under the Agreement on Technical Barriers to Trade
("ATBT"), an international standard is one (and the preferred) method
of*preparing
* national technical regulations. *E.g.,* ATBT article 2 section 2.6, <
http://www.wto.org/english/res_e/booksp_e/analytic_index_e/tbt_01_e.htm#article2
>:

With a view to harmonizing *technical regulations* on as wide a basis as
possible, Members shall play a full part, within the limits of their
resources, in the *preparation* by appropriate international standardizing
bodies of *international standards* for products for which they either have
adopted, or expect to adopt, *technical regulations*.

ATBT article 2 section 2.2 provides in relevant part:

Members shall ensure that technical regulations are not *prepared*, adopted
or applied with a view to or with the effect of creating unnecessary
obstacles to international trade.

So we need be concerned with understanding what a legitimate *technical
regulation* is to comprehend what a legitimate *international* standard is.


The World Trade Organization Appellate Body spoke to just that subject in
WTDS 135 EC - Asbestos (March 12, 2001), <
http://www.wto.org/english/tratop_e/dispu_e/cases_e/ds135_e.htm> (HTML
preview version, which includes paragraph numbers. See DOC version for text
original attributes. The emphases in this quoted portion are mine):

66. ... Article 1.2 of the TBT Agreement provides that, for the purposes of
this Agreement, the meanings given in Annex 1 apply. Annex 1.1 of the TBT
Agreement defines a "technical regulation" as a:

Document which lays down product characteristics or their related processes
and production methods, including the applicable administrative provisions,
with which compliance is mandatory. It may also include or deal exclusively
with terminology, symbols, packaging, marking or labelling requirements as
they apply to a product, process or production method. (emphasis added)

67. The heart of the definition of a "technical regulation" is that a
"document" must "lay down" - that is, set forth, stipulate or provide -
"product characteristics". The word "characteristic" has a number of
synonyms that are helpful in understanding the ordinary meaning of that
word, in this context. Thus, the "characteristics" of a product include, in
our view, *any objectively definable "features", "qualities", "attributes",
or other "distinguishing mark" of a product**.* Such "characteristics" might
relate, inter alia, to a product's composition, size, shape, colour,
texture, hardness, tensile strength, flammability, conductivity, density, or
viscosity. In the definition of a "technical regulation" in Annex 1.1, the
TBT Agreement itself gives certain examples of "product characteristics" -
"terminology, symbols, packaging, marking or labelling requirements". These
examples indicate that "product characteristics" include, not only features
and qualities intrinsic to the product itself, but also *related
"characteristics",* *such as the means of identification*, the presentation
and the appearance of a product. In addition, according to the definition in
Annex 1.1 of the TBT Agreement, a "technical regulation" may set forth the
"applicable administrative provisions" for products which have certain
"characteristics". ...

68. The definition of a "technical regulation" in Annex 1.1 of the TBT
Agreement also states that "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**.* It follows that, with
respect to products, a "technical regulation" has the effect of prescribing
or imposing one or more "characteristics" - "features", "qualities",
"attributes", or other "distinguishing mark".

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

70. A "technical regulation" must, of course, be applicable to an *identifiable
product,* or group of products. Otherwise, enforcement of the regulation
will, in practical terms, be impossible. ...
So will ODF v. 1.2 specify an "identifiable product?" Will ODF v. 1.2 be a
platform for product differentiation or will it specify "*any* objectively
definable 'features', 'qualities', 'attributes', or other 'distinguishing
mark' of a product?" Will ODF v. 1.2 specify a "means of identification" for
an identifiable product?

These are not difficult questions. But their answers are vitally important.
As it says on the web site of the European Committee for Interoperable
Systems, of which IBM is a member:

Interoperability is a cornerstone of the ICT industry. In today's networked
ICT environments, devices do not function purely on their own, but must
interact with other programs and devices. A device that cannot interoperate
with the other products with which consumers expect it to interoperate is
essentially worthless. It is interoperability that drives competition on the
merits and innovation. The ability of different computer products to
interoperate allows consumers to choose among them. Because consumers can
choose among them, interoperable products must compete with one another, and
it is this competition that has driven innovation in the software industry.

<http://www.ecis.eu/inter/index.html>

But here is what ECIS has to say about ODF. <
http://www.ecis.eu/inter/interoperability_and_open_standards.html>:

*In an attempt to introduce widespread interoperability, competition, and
consumer choice* to this application area, major industry players have
created a truly open standard for office productivity applications, called
the Open Document Format (ODF).
...

By definition an open standard has the following essential characteristics:
...

*Faithful implementations of the standard must interoperate.
*
We need not tarry to investigate and decide whether ECIS staff were merely
ignorant or deliberately lying to the public when they drafted that
paragraph. It is sufficient that you and I both know the claim of ODF
interoperability and consumer choice is false.

My question is whether ODF v. 1.2 will make the myth of ODF interoperability
come true. If there is one thing the file format war teaches it is that it's
easy to talk the interop talk. I ask something different, whether ODF v. 1.2
will walk the interop walk under your leadership.


> That's my observation at least, based on what I've seen.  But who
> knows.... If ISO C++ could require that implementations document their
> extensions, why can't it require that they provide GPL'ed source code as
> well?  There are all sorts of ways you can push the envelope here.  The art
> is finding a way that will gain acceptance.
>

It is a question that need not be reached. Standards cannot lawfully grant
conformant status to extensions that are not themselves specified as part of
a revised standard.

Finally, you might consider the fact that if vendor-extended versions of ODF
are classified as conformant, then IBM gave away its entire patent cookie
store as to any conceivable extension to ODF in the IBM  Interoperability
Specifications Pledge definition of "covered specification." <
http://www-03.ibm.com/linux/opensource/isplist.shtml> footnote 1.

*E.g., *right now the ODF conformance section would allow Microsoft to
implement OOXML using ODF as the container using its own unique namespaces.

ODF doesn't even have a mandatory requirement that foreign elements and
attributes not be used for functionality specified in ODF. Virtually the
only real conformance requirement in ODF is that documents validate against
the ODF schema *after all foreign elements and attributes are removed.* So
OOXML in an ODF container would be valid and conformant ODF. Heck, Microsoft
could park binary documents in ODF and still validly claim conformance.

Moral of the story: it's problematic to say the least to try to draft a
standard that allows your company to embrace and extend the standard and
still claim conformance but denies other companies the right to do the same.


For what it's worth, here is my current list of interoperability checkpoints
derived from applicable law and JTC 1 Directives that ODF and OOXML fail:

   1. Full-featured editors available that do not generate
   vendor-specific extensions?
   2. Interoperability of implementations mandatory?
   3. Interoperability between different IT systems demonstrated?
   4. Profiles developed and required for interoperability?
   5. Methodology specified for interoperability between less and more
   featureful applications?
   6. Specifies conformity requirements essential to achieve
   interoperability?
   7. Interoperability conformity assessment procedure(s) formally
   established and validated?
   8. Document validation procedures valid?
   9. Specified interoperability framework?
   10. Vendor-specific extensions classified as non-conformant?
   11. Preservation of metadata necessary to achieve interoperability
   mandatory?
   12. XML namespaces for incorporated standards properly implemented?
   (ODF-only failure because Microsoft didn't incorporate any relevant
   standards.)
   13. Optional feature interop breakpoints eliminated?
   14. Scripting language fully specified for embedded scripts?
   15. Hooks fully specified for use by embedded scripts?
   16. Portable cross-platform? (OOXML-only failure)
   17. Adequate cultural and linguistic adaptability?
   18. IPR restrictions absent?
   19. Vendor- and application-neutral?
   20. Capable of converging desktop, server, Web, and mobile device
   editors and viewers? (ODF-only failure but OOXML only within the context of
   the Microsoft stack)
   21. Responsiveness to market requirements for interoperability?
   22. Does not create ATBT unnecessary obstacles to international trade?
   23. Does not violate antitrust laws?

Granted that OpenDocument is more open than OOXML. Otherwise, the only
substantial differences I see are in the number of victims created by their
respective myths of interoperability.

Is Rob Weir going to do something about that situation in ODF v. 1.2? I do
not see much future for ODF if ODF implementations cannot even interoperate
with each other. Microsoft at least offers interoperability within its own
stack now reaching out to embrace,   extend, and monopolize the Office 2.0
space. No one is even trying to compete with them in the interoperable
office productivity software sector except those who have bought into the
myth of ODF interoperability.

Is an oligopoly somehow better for software users than a monopoly? I don't
think one can rationally defend that proposition without buying into the
fallacy that competing standards are a Very Good Thing.

But the view from here is that this is precisely what you propose to do by
classifying embraced and extended ODF as conformant. That scenario only
works to the benefit of entrenched market leaders who want to lock in their
customers.

There is a huge difference between competing with Microsoft and aping its
behavior. Embrace and implement interoperability and ODF might still
survive.

I have little doubt that IBM has decided that because of its victory in the
Court of First Instance and its position in the DG Competition investigation
of OOXML, ODF must require disclosure of the functionality of extensions.
But the Court of First Instance decision was not dealing with the context of
setting standards.

Please go to the  IBM lawyers and tell them that a crazy old man who knows
and thing or two about the law governing standards says that IT standards
may not lawfully confer conformant status on vendor-specific extensions.
Standards are about product uniformity, not about product differentiation.
You may lawfully tweak the implementing app and you may lawfully extend a
standard. But you may not brand an embraced and extended version of a
standard as conforming with that standard. Moreover, the standard may not
confer such status on extensions.

I will close by noting that I can conceive of no purpose for requiring the
disclosure of extensions' functionality other than facilitating
interoperability. But trying to implement interoperability in extensions to
a standard while neglecting the interoperability of what is specified by the
standard is akin to polishing the skin of a rotten apple. Why bother?

Or as stated in one of the maxims of equity jurisprudence: "Equity does not
require an idle gesture;" sometimes stated as "equity will not compel a
court to do a vain and useless thing." It's the judicial way of saying,
"kiss off; I've got more than enough stuff to work on that actually matters
and your case isn't worth cutting into my golf schedule."

I doubt that what you propose would be enforced by a court in any event.
It's an exercise in futility. Courts do not exist to polish the skin of
rotten apples.

Fix it or lose it.

Best regards,

Paul Merrell ("Marbux")
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20080409/07acbeec/attachment.html