Archives for July 2007

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.

This is taken from slide 21 of Ecma’s “Standards @ Internet Speed” presentation (22 June 2007 version) which you can download here. It appears to be a sales pitch.

I’ve joked about the Ecma process before, but I never thought I’d see it written out officially like this. Standards are made available “on time”? Minimize the “risk” of changes? I thought the whole purpose of technical review was to find the problems and fix them? As always, the man who pays the piper calls the tune.

(Also, you gotta love the “wink and nod” approach to patents on slide 16, where they can pretend a problem doesn’t exist if one member disputes that a patent is essential to implement the standard.)

The Thimbleberry Inn’s executive chef, Guillaume Portes, was sensational. He took the modest kitchen of this even more modest inn, and using local produce and game, and with a flair for the dramatic, created a menu that drew local, regional and even national attention, in ever widening spirals of epicurean and gastronomic success.

Now, fresh back from a guest appearance on a cable cooking show, Guillaume received a call from a publisher, asking if he would be interested in writing a cookbook: “Everyone loves your food. You’re a genius. If you write a cookbook we could sell millions.”

Guillaume at first was skeptical, “Me, write a cookbook? But I know nothing of writing!”

“Don’t worry,” said the publisher. “I’ll set you up with our best editor, Frank Morris. Frank knows writing. He does all of our celebrity books. It will be a wonderful collaboration.”

A few months later and the cookbook was almost ready to publish. The review copies went out in expectation of rave flap blurbs. But what came back…well…it wasn’t quite what they had expected:

1. Complaints that the Inn’s most popular dishes were not included. “Why did you leave out your most popular dish, the Pecan Stuffed Pheasant?”
2. Reports that some recipes were missing steps in their instructions, or that the specified ingredient amounts were vague, missing or incorrect. “One spoon of salt? It would help if you were more specific. Tablespoon or teaspoon?”
3. Some recipes had ingredients listed that did not seem to be used in the recipe. “What do I use the scallions for? They are listed as ingredients, but nothing explains how or when they are used.”
4. Observations that some instruction steps were vague or relied on unusual sources of information. “How are we to interpret a recipe step that says ‘Cook it like Aunt Mable used to cook it’ !”
5. Recipes were missing sauces or said simply, “Add your own sauce.” But the Thimbleberry Inn was famous for their sauces. How could any one replicate their dishes if the recipe for their signature thimbleberry sauce was omitted?
6. A huge number of typographical errors, broken references, inconsistencies, etc., that showed that the preparation of the cookbook was hasty and lacked sufficient review.

The publisher was confused. The editor was aghast. Guillaume was furious. How could the reviewers do this to us? Back stabbers! How dare they! These dishes are the finest in the country. Everyone who comes to the Inn loves and praises them. Look at the restaurant reviews! Look at my prize medals! Surely the reviewers must be in league with my competitor, the evil Gooseberry Inn, and are merely trying to prevent my book from selling!

The greatest dose of abuse was reserved for those reviewers who reported the greatest number of problems.

As the imprecations grew more passionate, and the volume and temperature rose, a timid voice arose from the back of the room, saying, “Uh, but are they right?”

The room grew silent as Fred Osgood, an old-timer, once editor-in-chief, but now on the verge of retirement, spoke his mind:

I’ve been in this business quite a while, as you all know. I’ve edited cookbooks before, plenty of them. None for a client as big as the Thimbleberry Inn, but the ones I did edit received good reviews and were modest successes in their day.

Frank, I don’t think you’ve ever edited a cookbook in your life, have you? I didn’t think so. The thing you need to know is that cookbooks require careful technical review as well as standard editing. Just because a chef is talented, or a restaurant is popular does not guarantee that the recipes and the cookbook are good. A recipe is not a dish. There is a lot of time and hard work required to turn Guillaume’s natural genius in the kitchen into something that readers of our cookbook can replicate in their own kitchens.

Back when I edited cookbooks, I made sure that we set up a test kitchen and verified every step of every recipe. We cooked, revised, and cooked again until we could say that every recipe worked as written.

I have no doubt that Guillaume can cook every one of these dishes from memory and get it right every time. I don’t think any of us can question that. But that is not the important question. The cookbook is not for Guillaume’s benefit. The question we need to ask is whether our readers can cook these dishes using these recipes. In other words, are the recipes relevant, complete and accurate? This is what makes writing a cookbook different than cooking, and this is where we have failed our readers. The reputation of the Thimbleberry Inn as well as this publishing house depends on us doing this right. We need to send this cookbook back for full and proper technical review.

The room was silent for a minute, as the others gazed at their feet. Then a smirk came over Guillaume’s face and he struck his fist loudly on the table, stood up and said:

But I need this cookbook now! We must do a better job at finding good reviewers. Let’s throw out the reviews we have so far. Let me give you the names of some of my friends, partners and former colleagues. Don’t even bother sending them a review copy. They don’t need to read it. They’ve all eaten at the Inn. They know how good my food is. Just have them fax over their reviews. Let’s get moving, gentlemen! The 2nd edition of the Gooseberry Inn’s cookbook is due out any month now. We can’t be left behind!

Old Fred silently collected his things and left via the back door, muttering.