Here begins the lesson on Embrace, Extend and Extinguish (EEE). Classically, this technique is used to perpetuate vendor lock-in by introducing small incompatibilities into a standard interface, in order to prevent effective interoperability, or (shudder) even substitutability of competing products based on that interface. This EEE strategy has worked well so far for Microsoft, with the web browser, with Java, with Kerberos, etc. It is interesting to note that this technique can work equally well with Microsoft’s own standards, like OOXML.
An easy way to find these extension points is to search the OOXML specification for “application-defined” or “implementation-defined”. You will find dozens of them, such as:
- In general, scripting
- In general, macros
- In general, DRM
- Part 1 — “Application-Defined File Properties Part” which is totally undefined, but is referenced 13 times for specific fields in Part 4.
- Section 126.96.36.199 — implementation-defined date/time formatting
- Section 188.8.131.52 — implementation-defined document filters
- Section 184.108.40.206 — implementation-defined string–>number conversions in a spreadsheet
- Section 220.127.116.11 — character sets supported by a font
- Section 2.9.6 — the interpretation of the mysterious hex “template code” in numbered list overrides — “The method by which this value is interpreted shall be application-defined.”
- Section 2.14.27 — application-defined storage of exclusion data for a mail merge
- Section 18.104.22.168 — application-defined cryptographic hash algorithms
- 22.214.171.124 — “Specifies a string identifier which may be used to locate the XSL transform to be applied. The semantics of this attribute are not defined by this Office Open XML Standard – applications may use this information in any application-defined manner to resolve the location of the XSL transform to apply.”
- Section 126.96.36.199 — application-defined macro string reference for connection shape
- Section 188.8.131.52 — application-defined macro string reference for graphic frame
- Section 184.108.40.206 — application-defined macro string reference for a picture object
- Section 220.127.116.11 — application-defined macro string reference for a shape
- Section 18.104.22.168 — application-defined macro string reference for a connection shape
- Section 22.214.171.124 — application-defined macro string reference for a graphic frame
- Section 126.96.36.199 — “This element specifies the presence of an ink object. An ink object is a VML object which allows applications to store data for ink annotations in an application-defined format.”
- Section 188.8.131.52 — implementation-defined bibliographic citation formats
- And many, many more.
So, one might ask, what exactly does “implementation-defined”mean? Here is how OOXML defines it and related terms:
behavior, implementation-defined — Unspecified behavior where each implementation documents that behavior, thereby promoting predictability and reproducibility within any given implementation. (This term is sometimes called “application-specific behavior”.)
behavior, locale-specific — Behavior that depends on local conventions of nationality, culture, and language.
behavior, unspecified —Behavior where this Standard imposes no requirements. [Note: To add an extension, an implementer must use the extensibility mechanisms described by this Standard rather than trying to do so by giving meaning to otherwise unspecified behavior. end note]
Note that this is not an entirely novel definition. Anyone who has spent time reading over the C and C++ Programming Language standards, in ANSI or in ISO, will recall a similar set of definitions. For example, these from ISO/IEC 9899:1999 C-Programming Language:
unspecified behavior where each implementation documents how the choice is made
behavior that depends on local conventions of nationality, culture, and language that each implementation documents
behavior where this International Standard provides two or more possibilities and
imposes no further requirements on which is chosen in any instance
So, you can see that OOXML pretty much copies these definitions. However, ISO standards like ISO/IEC 9899:1999 go one step further and make an additional statement in their conformance clause, something that is distinctly missing from OOXML:
“An implementation shall be accompanied by a document that defines all implementation-defined and locale-specific characteristics and all extensions.”
If you poke around you will see that all conformant C compilers indeed do come with a document that defines how their implementation-defined features were implemented. For example, GNU’s gcc compiler comes with this document.
So, by failing to include this in their conformance clause, OOXML’s use of the term “implementation-defined” is toothless. It just means “We don’t want to tell you this information” or “We don’t want to interoperate”. Conformant applications are not required to actually document how they extend the standard. You can look at Microsoft Office 2007 as a prime example. Where is this documentation that explains how Office 2007 implements these “implementation-defined” features? How is interoperability promoted without this?
(This item not discussed at the BRM for lack of time.)
This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License.