[odf-discuss] OOXML: The next step

Wed Apr 9 19:40:58 EDT 2008

Paul,

Your views are idiosyncratic at best.  By your argument, XML, XPath, 
XHTML, SMTP, HTTP and  C++, plus most other standards that comprises the 
modern IT infrastructure all are in violation of international law and all 
break interoperability, since they all allow proprietary extensions. 

Is that what you are asserting?

Regards,

-Rob

marbux <marbux at gmail.com> 
Sent by: odf-discuss-bounces at opendocumentfellowship.com
04/09/2008 06:48 AM
Please respond to
ODF Discussion List <odf-discuss at opendocumentfellowship.com>

To
"ODF Discussion List" <odf-discuss at opendocumentfellowship.com>
cc

Subject
Re: [odf-discuss] OOXML: The next step

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

_______________________________________________
odf-discuss mailing list
odf-discuss at opendocumentfellowship.com
http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20080409/5c295090/attachment-0001.html