Competition Optional

Regular readers will recall previous posts where I wrote about the abuse of language in the file format debate, including individual posts on the words choice, representation, compatibility and interoperability. Now it is time to slay another dragon, the word “optional.”

The OED defines optional as, “That is a matter of choice; depending on choice or preference; that may be done or left undone according to one’s will or pleasure.”

So volition plays a role. The matter that is optional is done or not done according to someone’s will. Someone has a choice. It is important to inquire who this person is. If someone says that “torture is optional,” we will be left with a rather imperfect knowledge of the circumstances unless we are also told whether the torture is at the option of the jailer, or of the prisoner.

More on the volition question a bit later.

In previous posts I have pointed out numerous “features” in OOXML which cannot be implemented by anyone else but Microsoft. These stem from a variety of causes, including elements lacking definition (“lineWrapLikeWord6”) to features that are tied to Windows or Office (e.g., Windows Metafiles) to items that are “merely referenced (OLE, digital ink) to items that although featured prominently in Office marketing materials, are curiously not mentioned at all in the OOXML text (scripts, macros, DRM, SharePoint, etc.). When these issues are raised, the typical response from Microsoft has been along the lines of, “Don’t worry, these features are optional. You don’t need to implement them. They are there for implementations that know what they mean. If you don’t understand them, you can ignore them.”

Let’s drill into this argument a bit more.

In the case of a person using an OOXML-supporting word processor, there are at least five levels of “optional” to consider:

1. At level of the XML, what constraints does the XML schema define? What elements and attributes are required, which are optional?
2. At the level of the OOXML conformance clause, what in the standard is optional and what is mandatory?
3. From the application vendor’s perspective, what features must be implemented in order to have a commercially viable product?
4. From the document author’s perspective, what features must a competitive word processor have when creating an OOXML document?
5. From the reader’s perspective, what level of features must a competitive word processor have to give a high fidelity presentation when reading an OOXML document?

It should be noted that 1 and 2 are closely related, and that 3, 4 and 5 are closely related. However, (1,2) and (3,4,5) have no necessary relationship with each other. It is entirely possible for a standard to define a schema and a conformance clause that describe a commercially inadequate set of features.

So what is required in OOXML, according to the standard? What must a word processor support if it wants to claim that it is conformant? The answer is given in OOXML’s conformance clause (Part I, Section 2.5 “Application Conformance”):

A conforming consumer shall not reject any conforming documents of the document type expected by that application.

That’s it. Conformance is defined in the negative: A conformant word processor must not give an error message when it is presented with a valid DOCX file. It does not need to do anything in particular with that document, but it can’t reject it. There are no mandated features, no required functionality. Under the provided conformance clause a conformant OOXML consumer can be as simple as the DOS command:

del *.docx

This is fully conformant since the delete command does not reject conforming documents.

So I find it highly disingenuous for Microsoft to argue that portions of the spec are permissibly undefined, vague or even incorrect on the grounds that they are optional. Everything in OOXML is optional. This should be repeated until it sinks in. Everything in OOXML is optional. So the argument that flaws are allowable in optional features can be used to allow any and all errors. But in fact there is nothing in ISO Directives or practice that excuses optional features from being fully or correctly defined. A feature being optional is a statement about conformance, not a license for reduced specification quality.

Back to the earlier dictionary definition of “optional”, where we inquired about whose volition was being expressed. In the case of features which are optional based on the OOXML conformance clause, whose volition is being expressed? The end user? No. When the end user receives a document, they expect it to be rendered according to the author’s intent. The author of the document has no idea when they are using optional features of OOXML. And if the document was translated from a legacy binary document, it may contain, unknown to that user, VML and various compatibility flags. If this document is edited and then forwarded to another user, that 2nd user also has no idea what markup is within the DOCX file. But they do have the expectation that their document will open and render properly. Despite Microsoft’s assurance that this is not a problem, since these features are optional, our poor little users may beg to differ.

What about the application vendor, is their volition expressed when OOXML says a feature is optional? Not at all. If a vendor wishes to create a commercially viable, competitive word processor, they must support the features that their customers’ documents contain, regardless of where these documents originated. Whether Microsoft calls these features “optional” or even “out of scope”, the fact remains that a vendor who does not implement them will be at a competitive disadvantage, and a “standard” that refuses to document fully these features will ensure and perpetuate this disadvantage.

From the application vendor’s perspective, it is an abuse of language and logic to call something “optional” if it is not fully documented. If it is not documented, then a vendor cannot implement it even if they wanted to. There is nothing optional about it, since there is no way to opt-in. Furthermore, if a vendor did manage to provide their own understanding of such a feature, via reverse engineering, or via other documentation not included in the standard, they would not be covered by Microsoft’s patent covenant, since that applies only to items that are “described in detail” in the standard.

When the OOXML standard says something is optional, it is speaking from the perspective of the author of the standard, Microsoft. Although it may fit well with their business strategy for would-be competitors to lack the technical information necessary to create competitive products, I do not find that this is a proper object for a would-be ISO standard.

ISO defines a standard as:

[A] document, established by consensus and approved by a recognized body, that provides, for common and repeated use, rules, guidelines or characteristics for activities or their results, aimed at the achievement of the optimum degree of order in a given context. (ISO/IEC Guide 2:2004, definition 3.2)

A key phrase is, “for common and repeated use.” This means that a standard must defines things that can be practiced in a repeatable manner by others. For a standard to include items that cannot be practiced by others, purely due to lack of a coherent definition, is antithetical to the purpose of a standard.

The next time that Microsoft asserts that these flaws are acceptable, because the flawed feature is “optional” we should ask them whether they believe also that competition is optional, since that is the net effect. To claim that the OOXML standard is the key to backwards compatibility with legacy documents while at the same time failing to document the very features that enable this legacy support — this is a sham. To justify this by arguing that such features are “optional” is neither good logic, good engineering, nor good standards development.