Rob

A Barleywine

2007/02/04 By Rob 5 Comments

According to the BJCP style guidelines, an English Barleywine is:

The richest and strongest of the English Ales. A showcase of malty richness and complex, intense flavors. The character of these ales can change significantly over time; both young and old versions should be appreciated for what they are. The malt profile can vary widely; not all examples will have all possible flavors or aromas.

Usually the strongest ale offered by a brewery, and in recent years many commercial examples are now vintage-dated. Normally aged significantly prior to release. Often associated with the winter or holiday season.

I started this batch back in November, with Belgian toasted malts (Dingemans Special B and Biscuit) and Target, Cascade and Fuffgle hops. The starting specific gravity (O.G.) was 1.112, which is one seriously heavy wort.

The previous day I had made a yeast starter, building a Wyeast #1056 American Ale 125ml “smack pack” into a 600ml starter (650 ml water 3/4 cup DME boiled for 15 minutes). For high gravity beers this is essential in order to get the fermentation off to a fast start.

After 2 1/2 weeks, the fermentation slowed enough to rack into a carboy where it sat for another month. Today I finally had a chance to bottle this, yielding 11 liters of barleywine. Final gravity was 1.034 giving an estimated ABV of 10.3%, a potent brew indeed. By way of reference, Budweiser is 5%.

An initial taste indicated that it was nicely balanced and hid the high alcohol levels behind the maltiness with forward hints of licorice, vanilla and plum. I will let it bottle condition for another 6-months or so before trying again. This will be a beer to sip and enjoy for several years.

Note that no licorice, vanilla, or plum was ever added to this beer. It is pure beer, according to the German Reinheitsgebot — nothing but water, malted barley, hops and yeast. The rest is the magic of biochemistry, the enzymes released during the malting of the barley that convert the starches into sugar, the carmelization of these sugars during the roasting of the barley, the alcohols and esters produced by the fermenting of the yeast. Even after the yeast has done its work and settled out, the beer will continue to evolve and change over time. Compare the complexity of a serious, living beer like this to the mass-produced, always-the-same pale lagers that fill the store shelves, and you will never go back.

Declaring Bankruptcy

2007/02/04 By Rob 10 Comments

Lawrence Lessig called it email bankruptcy: when you have so many unanswered emails in your inbox that you decide to make a clean start and just admit to yourself, and to those who wrote, that you are not going to respond.

I have a related problem, interesting links I’ve collected and have meaning to blog about. But my links have accumulated far faster than I have been able to write about them. So I am declaring “link bankruptcy”. Here is my fire sale, a set of interesting topics for only pennies on the dollar:

Glyn Moody has the story about how platform dependencies has impacted one notable British institution.
Even more startling results in Korea, as reported in The Cost of Monoculture and the Korean Saga.
It is mainly in Polish, but some in English. More coverage of Open Standards in a new blog from Jacek Łęgiewicz.
In case you missed it the first time around, here is a wonderful essay by Dan Bricklin on “Software that Lasts 200 Years“. It made me think of what ramifications this has for file formats that aspire to longevity as well.
This looks interesting. A free OpenOffice Calc add-in for doing “fuzzy math” in OpenOffice.
Sweave adds ODF support to the open source R statistical analysis and graphing platform.
Docvert, an online REST service for converting Microsoft Word documents into ODF format.
I know someone was asking for this a few months ago — A Microsoft Works import filter for OpenOffice.
Office Migration Planning Manager (OMPM) allows bulk conversions of legacy Office binary documents to OOXML. Does anyone have something similar for ODF? Not just bulk conversion, but detection and reporting of possible conversion problems as well.
The eXtensibility Manifesto has some good schema design advice, including: #3 “Design of a data model focuses on all stakeholders’ requirements for the data.” #6 “Designs or components are not reinvented, but rather are leveraged where possible.”
“[Expert Witness] Alepin…alleged that the company [Microsoft]had subverted developers who used Microsoft’s version of Java ‘thinking they were developing multi-platform applications, but were actually developing Windows-specific applications’ “. From PC Pro News.
The Case For ODF — a recent presentation from OpenOffice Community Manager Louis Suarez-Potts.
“Office 2007 lacks some features of earlier versions of Office, and so it can’t fully support some Office files created in earlier versions. For example, Word 2007 cannot open Word files that contain multiple document versions, a feature supported by Word prior to Word 2007”. Anyone know what else is missing? From Directions on Microsoft.
A few months old — European Cities Do Away with Traffic Signs. Does anyone know how this has turned out?
Dashed Lines and their uses.
David Berlind over at ZDNet: “To me, Ecma is not a standards body. As evidenced by the DVD situation (which is ridiculous if you ask me), it’s little more than a puppet with a pipeline through which vendors can pump their proprietary technologies into the ISO standardization process (avoiding the rigor that should normally be applied to anything up for consideratoin as an ISO standard). As such, the ISO is sort of a joke too.”
“One trouble spot we encountered using Vista’s Explorer metadata organization tools was the lack of support for some of the file types we commonly use. For instance, JPEG files happily take attributes under Vista, but PNG files do not. Along similar lines, Vista would not apply metadata to files we had created in the OpenOffice.org format. And, strangely, our attempts to apply metadata to documents created in OpenOffice.org—in Microsoft Office format—were greeted with an error message.” From eWeek.
What is a standard, according to David Rudin, Microsoft’s official Standards Attorney? “A technical specification that enables interoperability between different products and services and is either 1) intended for widespread industry adoption or 2) has achieved wide spread industry adoption.” This is a nice write-up.

Introducing ODF 1.1

2007/02/02 By Rob 5 Comments

ODF 1.1 is now officially approved as an OASIS Standard in a ballot which ended Wednesday. Accessibility Subcommittee Co-Chair Peter Korn breaks the story.

I played but a bit role in this story, though I watched it unfold with amazement. It was late 2005. A colleague mentioned that there were rumblings of concern in Massachusetts about their recent decision to move to ODF and what impact that would have on persons with disabilities. Although I am not an accessibility expert, I know the basics. (Every programmer should know the basics of accessibility, as well as the basics of internationalization, typography, human factors, performance, security, law, technical writing, project management and how to present and receive business cards in Asia).

Initially, I suggested that a file format has no relevance at all for accessibility. After all, the hard part of accessibility, the integration with screen readers was all at the application and operating system level. What difference could a file format make? The file format is not even involved except when loading or saving the document, right? But since knew ODF, I offered to do a quick spot check and report back. It wasn’t long before I was able to demonstrate a handful of places where data necessary to enable accessibility was not described in the existing specification. For example, although an imported image allowed an annotation of alternate text for use by screen readers, an OLE embedding did not.

To err is human, but what happened next was extraordinary. There is a natural tendency to shrink away from criticism, to retreat inward and retrench, and at all costs avoid admitting errors. But I personally believe that every time we are corrected or criticized, it gives us another opportunity to show our character by how we handle it. The unchallenged person may be a gentleman or a scoundrel. You do not know until he is under pressure. So it is notable that the OASIS ODF TC overcame its accessibility problems not with defiance and not with acquiescence, but by enthusiastically embracing the challenge, engaging the critics, including the aggrieved community, bringing in the experts, both from OASIS member companies as well as outside invited experts, and working within an open and transparent standards development process, rolled up its sleeves and got to work.

The OASIS ODF Accessibility Subcommittee first met on January 27th, 2006. They delivered their evaluation report on ODF accessibility in June of 2006, followed by contributions to the ODF 1.1 specification which was approved as an OASIS Committee Specification in October, 2006, and just this week was approved by the OASIS membership as an OASIS Standard. This took a few days over a year, start to finish.

This is what open standards are all about and why they are so damn important. It isn’t just about patents and lawyers, though that is certainly part of it. It isn’t just about getting your specification approved by ISO, though that is certainly part of it. It isn’t just about how little you can do to earn the label of “open standard”. It is about how much we can do together to improve some parts of the technological landscape that are broken today for some users, and have been for some time.

Congratulations are due the members of the Accessibility Subcommittee for their diligent efforts. But we haven’t heard the last from them. Their charter calls for them to continue their good work, to make additional accessibility improvements to ODF, look at new dimensions of accessibility, consider a wider range of disabilities and create a guide for ODF implementors on the best practices for implementing the accessibility feature of the ODF standard.

I look forward to their contributions to ODF 1.2 and beyond!

More Matter with Less Art

2007/01/31 By Rob 29 Comments

I wish to discuss a recent blog post, a vigorous defense of Microsoft’s Office Open XML and XAML from Novell’s Miguel de Icaza. His post is so wrong, on so many levels, that I am somewhat at a loss for words. Miguel is not stupid, and I find it hard to believe that he is a Microsoft shill, so I must assume that he was imperfectly informed on this issue. “Everyone is entitled to their own opinions but they are not entitled to their own facts,” as Pat Moynihan was fond of saying. I’ll try hard not to make this personal, but there are so many errors in his post that he may very well feel the sting of correction in my words, and for that I apologize in advance.

I suggest you read through Miguel’s post in its entirely, and then return here for my response.

After an attack against lawyers, we come to some technical comments:

Unlike the XML Schema vs Relax NG discussion where the advantages of one system over the other are very clear, the quality differences between the OOXML and ODF markup are hard to articulate.

The high-level comparisons so far have focused on tiny details (encoding, model used for the XML). There is nothing fundamentally better or worse in those standards like there is between XML Schema and Relax NG.

ODF grew out of OpenOffice.org and is influenced by its internal design. OOXML grew out of Microsoft Office and it is influenced by its internal design. No real surprises there.

Maybe I can be of some assistance here, helping to articulate the difference in quality between ODF and OOXML. ODF, starting from its roots in OpenOffice.org specification, spent a further 2 1/2 years being improved and reviewed in OASIS, then further work preparing for submission to ISO, then a further year in ISO, receiving more comments and corrections, before it was published as an ISO standard. So this is a combined 4 years in technical committees being refined by standards bodies. During this time ODF has been implemented in dozens of applications, including full suites like OpenOffice.org, KOffice and Lotus Workplace, as well as individual applications like AbiWord, Gnumeric and Google Docs and Spreadsheets.

In comparison, OOXML went from a proprietary Microsoft specification to an Ecma standard in record time. If you make something 8 times lengthier than ODF, and do it 4 times faster than ODF, then you are going to have a quality problem. The list of problems on GrokLaw is one list of known problems in OOXML. Note that particular list was generated in only 3 or 4 days by volunteers. I recently did a sampled survey of OOXML specification quality and predicted that it contains thousands of errors.

And where are the OOXML implementations? OOXML was approved by Ecma and submitted to ISO without a single available implementation. Certainly, Office 2007 later shipped with support, but is that it? A single implementation? Until you have at least two independent implementations of a standard you will have a very imperfect understanding of the standard’s quality.

So the question to ask is this: Why should JTC1 NB volunteers deal with the mess that Microsoft dropped on their lap by their overhasty review of OOXML in Ecma? Why should they spend the next 6 months reviewing this specification when even a cursory review shows it is defective in so many ways? And considering the observed low level of quality, why should it be reviewed and approved via a Fast Track process, and all in one big chunk of 6,000 pages? Isn’t this the last thing you want to do, following up a rushed review in Ecma by a rushed review in ISO? Instead this should go back to Ecma to let them do a proper review, one they can be proud of.

Miguel correctly points out that OOXML derives from Microsoft Office’s formats, and ODF derives from OpenOffice.org’s formats. But then he leaps to an assertion that they both reflect their parent application’s internals. This is not true. Only a poorly-designed file format reflects the internals of the application. Maybe that is how we did it back in the 1980’s, but best-practices for portable file formats have been known for years now. That is why we have data formats like XML, so the format can be independent of the application internals. ODF was designed, even in the OpenOffice days, from the ground up to be an application- and platform-neutral document format. While it was further developed in OASIS, it continued to take on such good qualities as reuse of existing relevant W3C standards such as XForms and MathML and SVG. So certainly, the platform-independence and open nature of OpenOffice.org rubbed off on ODF, but isn’t that an extremely good thing?

OOXML, on the other hand, matches to an inane degree the internals of a single vendor’s legacy application, with no concessions to platform-neutrality. For example, OOXML encodes data in non-XML formats such as binary blobs, bitmasks and other encodings that defy XML schema validation or processing by XML tools. As I’ve said before, this is not a specification, this is a DNA sequence.

Does that help articulate the difference?

Miguel then takes on the size question:

A common objection to OOXML is that the specification is “too big”, that 6,000 pages is a bit too much for a specification and that this would prevent third parties from implementing support for the standard.

Considering that for years we, the open source community, have been trying to extract as much information about protocols and file formats from Microsoft, this is actually a good thing.

This is good thing, I agree, that Microsoft has produced this specification. I’d like even more for them to make the specification for the Office binary formats public, since that is the format that the billions of legacy documents are actually in. I hope you’ll join with me in calling for Microsoft to release the specification for these formats under their Open Specification Promise, so that users will truly be able to choose which format they want to remain in or move to.

However, merely because it is useful from a disclosure perspective, does not necessarily mean it will make a good standard. Simply because it is better than nothing does not mean it is sufficient for an ISO standard. There is an important difference between a descriptive specification and a prescriptive standard. Writing down file formats is a small virtue, and one that other companies have done for years. Do they all deserve to be ISO standards?

For example, many years ago, when I was working on Gnumeric, one of the issues that we ran into was that the actual descriptions for functions and formulas in Excel was not entirely accurate from the public books you could buy.

OOXML devotes 324 pages of the standard to document the formulas and functions.

….

Depending on how you count, ODF has 4 to 10 pages devoted to it. There is no way you could build a spreadsheet software based on this specification.

This is a rather bold misstatement, considering that implementations such as OpenOffice.org, KSpread, Gnumeric, Google Spreadsheets, Lotus Workplace, etc., already in fact exist. Go back even earlier, we had 1-2-3, Quattro Pro and OpenOffice all supporting Excel’s formulas even though there was no formal specification for it. Sure having a good specification helps, but the extreme rhetoric that says that this is unimplementable is patently absurd. Just look around.

Some folks have been using a Wiki to keep track of the issues with OOXML. The motivation for tracking these issues seems to be politically inclined, but it manages to pack some important technical issues.

Hmm… The open source community helps test a purported open standard, reports the defects it finds, and this is called “politically inclined”? Isn’t this what open source is all about, “given sufficient eyeballs, all bugs are shallow”? Shouldn’t open standards be subject to scrutiny? As I said in my blog, I am so impressed by the quality and productivity of this type of wiki-enabled public review that I am going to investigate how we can do this to solicit public comments on ODF 1.2. This isn’t for political reasons. This is because it works.

Some of the objections over OOXML are based around the fact that it does not use existing ISO standards for some of the bits in it. They list 7 ISO standards that OOXML does not use: 8601 dates and times; 639 names and languages; 8632 computer graphics and metafiles; 10118-3 cryptography as well as a handful of W3C standards.

By comparison, ODF only references three ISO standards: Relax NG (OOXML also references this one), 639 (language codes) and 3166 (country codes).

Not only it is demanded that OOXML abide by more standards than ISO’s own ODF does, but also that the format used for metafiles from 1999 be used. It seems like it would prevent some nice features developed in the last 8 years for no other reason than “there was a standard for it”.

Miguel has inexplicably ommitted all of the W3C standards that ODF uses, such as XForms, MathML, SVG, XLink, SMIL, XSLT, CSS2 as well as IETF standards such as RFC 2045, RFC 2048, RFC 2616, RFC 2898, RFC 3066, RFC 3987. To imply that OOXML follows more standards that ODF is a foolish statement, unsupported by facts.

On the WMF, Miguel has it all wrong. What is a Windows Metafile? It is simply a recording of the graphical function calls made by Windows as it renders a drawing. It maps 1-to-1 into Windows API calls. It maps so closely to Windows that when the WMF format was found to be vulnerable to a security flaw, even the Wine Windows compatibility layer for Linux was susceptible to the same security hole. WMF (and VML, another legacy format in OOXML with a history of security problems) are flawed formats. One security vendor said: “Turns out this is not really a bug, it’s just bad design. Design from another era.” and “The WMF vulnerability probably affects more computers than any other security vulnerability, ever.”

Although Miguel is pleased to note that the proposed cross-platform ISO standard, Computer Graphics Metafile (CGM) dates to 1999, he fails to mention that WMF is even older, dating back to Windows 3.0 (1990).

So which one should be prefered in an ISO standard? The Windows Metafile format which is not documented in an open standard, is tied to the graphical layer of a single vendor, and has design flaws with serious security implications? Is this what we really want? Or do we want an open standard, one designed to be platform neutral, that has been in use for eight years, that has had a community continuing development and promotion of it such as CGM Open and WebCGM? Where is the WMF community? A Google search for WMF comes up with security problems; a search of CGM comes up with communities, initiatives and test suites.

There is an important-sounding “Ecma 376 relies on undisclosed information” section, but it is a weak case: The case is that Windows Metafiles are not specified.

It is weak because the complaint is that Windows Metafiles are not specified. It is certainly not in the standard, but the information is publicly available and is hardly “undisclosed information”. I would vote to add the information to the standard.

Did you really read the Groklaw issues list? WMF is not the only, or even the most troublesome of the undisclosed information in OOXML. Start here, then go back and read the Groklaw list of issues, and let me know if it makes more sense then. I am not that good at explaining these things, so please ask questions and I will try harder.

I have obviously not read the entire specification, and am biased towards what I have seen in the spreadsheet angle. But considering that it is impossible to implement a spreadsheet program based on ODF, am convinced that the analysis done by those opposing OOXML is incredibly shallow, the burden is on them to prove that ODF is “enough” to implement from scratch alternative applications.

There is that claim, that it is impossible to implement an ODF spreadsheet. Miguel, surely you aware of OpenOffice, KSpread, Lotus Workplace, Gnumeric, Google Docs? How can you persist in such obvious error? How could you actually write the above when you know, I know, and everyone reading it knows that it is patently false? Please tell me it was a just a typographical error.

Here’s a challenge: Give me a list of four spreadsheet applications from four different vendors that today are as interoperable with OOXML as the four leading ODF spreadsheets are with ODF.

There is a good case to be made for OOXML to be further fine-tuned before it becomes an ISO standard. But considering that Office 2007 has shipped, I doubt that any significant changes to the file format would be implemented in the short or medium term.

The best possible outcome in delaying the stamp of approval for OOXML would be to get further clarifications on the standard. Delaying it on the grounds of technical limitations is not going to help much.

This is quite a revealing statement. Why should the shipment of Office 2007 factor in the appropriateness and the quality of a proposed International Standard? Should standards of quality be relaxed for Microsoft’s convenience? Do technical limitations not matter because Microsoft has sales targets to meet? Is this what ISO is for? If so, I suggest their hard-working volunteers be given Microsoft salaries and stock options, since clearly they would be working only for Microsoft’s benefit at this point.

Miguel has a good point at the end:

To make ODF successful, we need to make OpenOffice.org a better product, and we need to keep improving it. It is very easy to nitpick a standard, specially one that is as big as OOXML. But it is a lot harder to actually improve OpenOffice.org.

If everyone complaining about OOXML was actually hacking on improving OpenOffice.org to make it a technically superior product in every sense we would not have to resort, as a community, to play a political case on weak grounds.

OpenOffice.org is one, but not the only application of ODF. It is the most prominent one in the traditional heavy-weight office suite model, but I’m not certain that this is the only way forward. We need good implementations, several of them, since one size does not fit all.

In any case I’d say in return that if Microsoft and Microsoft boosters spent some of their time investigating exactly how easy it would be to encode Office’s legacy features on top of the extensible ODF specification, and worked together with the ODF community to address their common concerns, then we could easily have a single interoperable format that we all could use. The resulting standard of OOXML on top of ODF would be smaller, simpler, higher quality and more interoperable than the mess that we’ll end up with by having OOXML as a standard, in addition to ODF.

Change Log:

2/1/2007 — fixed spelling errors reported by a reader via email
2/2/2007 — another spelling error

Defining Deviancy Down

2007/01/30 By Rob 10 Comments

Kai Erikson, in his classic study of deviant behavior in early New England, Wayward Puritans, made the important observation that:

…the amount of deviation a community encounters is apt to remain fairly constant over time. To start at the beginning, it is a simple logistic fact that the number of deviancies which come to a community’s attention are limited by the kinds of equipment it uses to detect and handle them, and to that extent the rate of deviation found in a community is at least in part a function of the size and complexity of its social control apparatus. A community’s capacity for handling deviance, let us say, can be roughly estimated by counting its prison cells and hospital beds, its policemen and psychiatrists, its courts and clinics.

In other words, a community’s perception of social deviation is conditioned and limited by their capacity for controlling it. With equal number of punishment cells, equal-sized communities of cloistered monks and bloodthirsty pirates would perceive the same rate of deviancy. Of course the actual deviations would be different: Brother Maynard isn’t praying earnestly enough versus Greybeard slit a crewmate’s throat in the night, without warning the bunkmate below.

The late Senator from New York, Daniel Patrick Moynihan, took this idea and applied it to the social ills that America has increasingly faced since the 1960’s: mental illness, illegitimacy and violent crime. How does society react when the level of deviancy rises unexpectedly and rapidly above accepted norms? He observed, in an essay entitled, “Defining Deviancy Down”:

[…T]he amount of deviant behavior in American society has increased beyond the levels the community can “afford to recognize” and that, accordingly, we have been re-defining deviancy so as to exempt much conduct previously stigmatized, and also quietly raising the “normal” level in categories where behavior is now abnormal by any earlier standard.

I look at the current situation with Office Open XML (OOXML) in a similar way. There is a clearly defined community — JTC1 member National Bodies — with the responsibility for reviewing submitted standards. However, their capacity for exercising control is finite. The JTC1 Directives allow them a fixed period of time to review any submission. They also have a fixed number of volunteers to perform the review, and a fixed (or at least highly constrained) number of meetings to discuss and agree on review comments. So, when presented with a specification of unprecedented length (over 6,000 pages), and rather low quality, what are they to do? Spend hundreds of hours reading the specification? Write up and report thousands of errors? No, the capacity in JTC1 to deal with this level of deviancy does not exist, so the natural way for the community to cope is to to define deviancy down.

How deviant is OOXML? The 6,000+ page length is one aspect. Another is the rate at which it raced through its Ecma review, 20-times the speed of comparable specifications. Certainly, a longer specification will tend to have more problems than a shorter one, and a rushed review will find fewer problems than a thorough one. But that is speaking in generalities. Is there anything we can say for OOXML defect rates?

The Groklaw review, which occurred over a few days found a large number of serious problems. But I think we can quantify this a bit more. I tried an experiment. I used a random-number generator to generate a sample of 20 page numbers in the OOXML specification. I then read each of these pages, looking for technical errors, platform dependencies, lack of extensibility, drafting errors, etc. I did not bother noting spelling, grammatical or usage errors. I recorded how many reportable errors I found on each page. Some pages had zero problems, others had 1, 2 or even 3 problems. I even found one particularly bad error that could send OOXML back to Ecma once reported — more on that another day — but the average errors per page was 1.0. So projecting out to a 6,039 page specification this leads to a prediction of 6,000 +/- 1,000 errors. Reviewing a larger number of pages would reduce the error bars on that prediction, but we seem to be dealing with defects numbering in the thousands.

Are NB’s able to deal with a level of deviancy this great? Do they possibly have the resources to detect and report this number of errors and then verify that they are addressed? If not, the natural reaction is to define deviancy down.

For example, OOXML is currently in a 30-day review period where “contradictions” with existing ISO or IEC standards can be alleged by National Bodies (NB’s). Although the word “contradiction” is not defined in JTC1 Directives, its meaning can be seen from a resolution unanimously adopted at a JTC1 Plenary in 2000:

Resolution 27 – Consistency of JTC 1 Products

JTC 1 stresses the strong need for consistency of its products (ISs and TRs) irrespective of the route through which they were developed. Any inconsistency will confuse users of JTC 1 standards and, hence, jeopardize JTC 1’s reputation. Therefore, referring to clauses 13.2 (Fast Track) and 18.4.3.2 (PAS) of its Directives, JTC 1 reminds ITTF of its obligation to ascertain that a proposed DIS contains no evident contradiction with other ISO/IEC standards. JTC 1 offers any help to ITTF in such undertaking. However, should an inconsistency be detected at any point in the ratification process, JTC 1 together with ITTF will take immediate action to cure the problem.

The clear meaning of this is that contradictions are to be avoided, and that some of the defining characteristics of standards with contradictions are that they are not consistent, that they confuse users, and that they jeopardize JTC1’s reputation.

Further, we have precedents of other contradictions raised within JTC1, such as just last year, when the NB’s of the UK and Germany both alleged contradictions against Microsoft’s C++/CLI specification, then submitted for Fast Track processing from Ecma. The contradiction raised by the German NB (DIN) in that case said in part:

On a technical level, there are some rather different approaches between C++ and C++/CLI which can easily cause considerable confusion when both languages are considered to be “C++” or add unnecessary overhead when trying to write C++ code usable with C++ and C++/CLI. Below are a few example although if there were sufficient time to to thorough analysis of the C++/CLI document more could probably be found.

This is simple, easy to understand, and well within the spirit of the JTC1 Resolution quoted earlier.

But in a notable case of defining deviancy down, we’re starting to see the word “contradiction” defined very narrowly. For example, Microsoft’s Brian Jones suggests contradictions should be looked at this way:

[T]his is where you want to make sure that the approval of this ISO spec won’t cause another ISO standard to break. In the case of OpenXML, there really can’t be a contradiction because it’s always possible to implement OpenXML alongside other technologies. For instance, OpenOffice will soon have support for ODF and OpenXML.

An example of a contradiction would be if there was a standard for wireless technology that required the use of a certain frequency. If by using that frequency you would interfere with folks using another standard that also leverages that frequency, then there may be a contradiction.

To be quite fair, the Chinese WAPI defeat in ISO is also a precedent, but when searching for a definition of “contradiction” all precedents should be considered, not just one. Arguing exclusively from a wireless protocol standard precedent when dealing with the case of an XML markup standard is dubious when contradictions just last year were alleged to a programming language, a technology much closer to OOXML than a wireless protocol is. Surely, since C++/CLI is Microsoft’s technology they would be aware of this precedent? But still they didn’t mention it.

I ask you to consider the impact of taking Microsoft’s definition of “contradiction” and applying it to virtual technologies, like document formats, image formats, presentation formats, programming languages, operating system interfaces, API’s, security protocols, anything in the realm of software rather than hardware. None of these can ever conflict by Microsoft’s definition. Never. Therefor there is never grounds for a contradiction, and JTC1’s own Directives, which adopted the contradiction clause only a few years ago, is a procedural nullity, a no-op, meaningless, a waste of time for a large part of the technologies JTC1 has standards authority for. This is a clear example of defining deviancy down.

Let’s go back in time, 750 years ago to Thomas Aquinas and his Summa Theologica, the 13th century’s God: The Missing Manual. Aquinas had some apt words on contradictions, when discussing whether the powers of God were infinite and omnipotent (Question 25, Article 3):

Therefore, everything that does not imply a contradiction in terms, is numbered amongst those possible things, in respect of which God is called omnipotent: whereas whatever implies contradiction does not come within the scope of divine omnipotence, because it cannot have the aspect of possibility… For whatever implies a contradiction cannot be a word, because no intellect can possibly conceive such a thing.

Aquinas here allows that God can do all things that are possible, but cannot do something which is a contradiction in terms. Going back to Microsoft’s proposed definition of a contradiction, it seems that they are only willing to acknowledge a contradiction if it amounts to a co-existence problem so severe that even God could not resolve it. This seems to be a rather high hurdle to reach, and is clearly not what JTC1 intended. This is defining deviances down, way down.

This is the essential problem JTC1 has with the OOXML submission. It is too large and has too many problems with it for the control mechanisms available to JTC1 (in particular review time and volunteers) for handling the presented level of deviancy. The only recourse available to them is to define deviancy down to the level where they can handle a much smaller number of problems. Of course, this will lead to a much lower-quality ISO Standard than we are accustomed to, but what other choice is there?

This lesson has clear ramifications for Microsoft. The bigger the specification, the less throughly it will be reviewed. If you make it large enough it will barely be reviewed at all. The plan for 2007 should be to combine the .NET, OPC, XPS, JScript, J#, C#, XAML, WPF, HD Photo and whatever other specifications you have handy, put them all into one 50,000 page document, call it the “Open Microsoft Specification” rush it through Ecma and then Fast Track it into ISO. No one can really stop you. JTC1 Fast Track is broken.