• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

An Antic Disposition

  • Home
  • About
  • Archives
  • Writings
  • Links
You are here: Home / Archives for 2006

Archives for 2006

And then there were three…

2006/12/27 By Rob Leave a Comment

ODF, OOXML and now, UOF. This story broke back in November, with some good coverage including:

  • Andy Updegrove: Another Open Document Format – From China and More on China’s Uniform Office Format (and much more)
  • Jeff Kaplan: Is China Pulling a Bill Gates on ODF?
  • David Berlind: China’s own document standard: A clear message to US IT vendors?
  • Rick Jelliffe: Why China’s UOF is good
  • Stephen Walli: Open Standards, IPR and Innovation Conference, Beijing (2006)
  • Neil McAllister: China aims to set a new office doc standard
  • Luyi Chen: China’s Own Office Document Format Aiming to Harmonize with ODF
  • Evan Leibovitch: Debate over document formats not just academic

There is not much commentary I can add to what the above authors have already stated. Let’s just say that this is an important and exciting development.

On the technical side there is some important progress on harmonization, some preparatory work done in a joint research program between Peking University and IBM. The results of this year-long effort are now available:

  • A 150-page report (in English and Chinese) called “A Comparison Between ODF and UOF”. This document compares the two standards feature-by-feature and explains how to map data between the two.
  • A UOF-ODF Convertor, an open source Java-based tool, licensed under the LGPL, which provides bi-directional conversions of the three office document types (word processor, spreadsheet and presentation).

The report, the tool, the source code and a lot more information is available up at the project’s page on SourceForge. I hope this both addresses the immediate-term interoperability needs between ODF and UOF, as well as lays the foundation for a deeper technical discussion of additional harmonization steps which can be taken to improve interoperability even further.

  • Tweet

Filed Under: ODF

Got ODF?

2006/12/21 By Rob 1 Comment

Are you writing code that works with ODF? Open source, commercial, in-house, internationally distributed, written in Python, Java, Ruby, C++ or Haskell, a one person project or with a team of dozens — if it is done with ODF and is interesting, then I want to hear about it and help share your story.

Here’s the deal. Drop my a line, via email or the comment form, and I’ll arrange to either call you or send you some interview questions via email, things like:

  • What did you do?
  • How did you do it?
  • What tools did you use?
  • Why ODF?
  • What worked well and what didn’t?
  • What next?

If the software is available for me to run and review, then so much the better.

I’ll then write up a story and feature it on my blog and on OpenDocument.xml.org. You’ll get some free publicity, and you’ll help me tell the continuing story of innovation with ODF. It’s a win-win, community thing. My intent to is have this be an ongoing feature in 2007.

I’m especially seeking anyone who is going beyond the traditional heavy-weight editor paradigm and is starting to look at other modes of use for ODF.

Feel free to share this invite with others who may be interested.

  • Tweet

Filed Under: ODF

A notable achievement

2006/12/09 By Rob 8 Comments

I believe congratulations are in order to Microsoft and Ecma’s TC45 for what appears to be a new world record for creating a standard. Their recently-approved Office Open XML (OOXML) standard weighed in at 6,456 pages yet took only 357 days to be reviewed, edited and approved, making it not only the largest markup specification, but possibly also the fastest to complete its standardization cycle.

To put the magnitude of this accomplishment into perspective, I looked at a variety of other successful standards from various standards bodies, such as:

  • OASIS OpenDocument Format (ODF)
  • OASIS Darwin Information Typing Architecture (DITA)
  • W3C Extensible Stylesheet Language (XSL)
  • W3C XHTML
  • W3C Scalable Vector Language (SVG)
  • W3C Simple Object Access Protocol (SOAP)
  • IETF MIME
  • Ecma C#
  • Ecma C++/CLI

In all cases I looked at how long the specification took to be standardized, from when the initial draft was made available (whether developed within the technical committee, or submitted by a vendor at committee formation) to the time when the standard was approved. So we’re looking at the complete editing/review/approval time, not including the time to author the initial draft. I also looked at the length of the resulting standard.

(Click on the above chart for a larger view)

As you can see, there is a noticeable trend with previous standards, where longer specifications took longer to edit, review and approve than shorter ones. This was the received wisdom, that standardization was a slow process, and this deliberate pace was necessary not only to achieve technical excellence, but also to socialize the specification and build industry consensus.

Also, previous specifications seemed to top out at around 1,000 pages. Larger than that and they tended to be broken into individual sub-standards which were reviewed and approved individually.

The general practice, as shown in this data, has been for standards to take from 0.1 – 1.2 pages per day, for a complete review/edit/approval cycle. Even other Microsoft specifications in Ecma have fit within these parameters, such as C# (1.2 pages/day) and C++/CLI (0.7 pages/day).

Thus the remarkable achievement of Microsoft and Ecma TC45, who not only managed to create a standard an order of magnitude larger than any other markup standard I’ve seen, but at the same time managed to complete the review/edit/approve cycle faster than any other markup standard I’ve seen. They have achieved an unprecedented review/edit/approval rate of 18.3 pages/day, 20-times faster than industry practice, a record which will likely stand unchallenged for the ages.

I think we would all like to know how they did it. High-altitude training? Performance enhancing drugs? Time travel? A pact with the Devil? I believe you will all share with me an earnest plea for them to share the secret of their productivity and efficiency with the world and especially with ISO, who will surely need similar performance enhancements in order for them to review this behemoth of a standard within their “Fast Track” process.

I am optimistic, that once the secret of OOXML’s achievement gets out, the way we make standards will never be the same again.


Change Log

1/26/07 — corrected two typographical errors pointed out by a reader

  • Tweet

Filed Under: OOXML, Standards

How to Write a Standard (If You Must)

2006/12/06 By Rob 6 Comments

Standards are generally a bad idea. They reduce freedom-of-action and limit choice. But sometimes you must have one in order to pacify an anti-business regulator or other socialist-leaning bureaucrat. So what should you do if you find you find yourself in the awkward position of coming up short in the standards department? By all means, create a standard and do it quickly! I offer here some observations on best-practices, and tried-and-true advice on how to make a standard quickly, with little pain or risk.

First some background. Standards writing, as generally practiced, is a multilateral, deliberative process where multiple points of view are considered and discussed, where consensus is reached and then documented. This must be avoided at all costs. The delays introduced by such a consensus process are considerable and the outcome of such a process does not justify that time investment. If you already have a monopoly, why waste time on a consensus? Consider the notable failures of XHTML, XForms, SVG, XSLT, etc. Look at the multiple implementations of these standards, including viral copyleft and IP-deficient products. Do you really want to see this trend continued?

Start with a complete product implementation. This makes the entire process much faster since there is no time wasted discussing such abstract, heady things as interoperability, reuse, generality, elegance, etc. Only Perpetual Adoration of the One True Implementation (the one you already have) will quickly lead to a specification. Avoid consideration of alternatives. Consideration of alternatives is your prime risk factor for introducing delay.

If possible choose an implementation that has layers of complexity from years of undisciplined agglomeration of features. Of course this will lead to a specification of Byzantine complexity and epic length. But since no one will actually read the specification, there is no harm. In fact the length and complexity can bring several benefits:

  1. Any criticism of the specification can automatically be dismissed as nitpicking. For example, if you are presented with a list of 500 faults in a 6,000 pages specification, you can respond, “That is less than 10%. You are just nitpicking. We can fix that in release 1.1”. Or you can even just rely on the familiar justification, “Shipping is a feature”. Any finite list of defects can be made minuscule by a sufficiently large specification.
  2. Further, since review periods at ISO and most other standards bodies are of fixed length, regardless of the length of the specification, a sufficiently large specification will ensure that it receives no, or only cursory review. Divide the length of the specification in pages, by the length of the review period in days. A Freshman English major might be assigned reading of 50 pages per day. Aim to double or triple this reading load. 100+ pages/day is a good rule of thumb to ensure that a volunteer on a standards committee will not be able conduct a thorough review.
  3. The pure size of the specification will imply to some that it is a well-considered, comprehensive and cohesive document. Just like the IRS tax regulations and the federal budget.
  4. In case of emergency the specification can be burned as fuel

Shop around for the best standards development organization (SDO), one that knows how to get the job done quickly. Evaluation criteria include:

  1. A proven ability to approve standards quickly. You are not interested in advancing the state of the art here. You want fast-in-fast-out-stamp-my-ticket processing so you can get on with your business.
  2. A membership model that effectively exclude individual experts and open source projects from the process.
  3. A demonstrated competency in maintaining needed secrecy when developing sensitive standards.
  4. The right to make FastTrack submissions to ISO

Ecma International approved the DVD-RAM, DVD-R, DVD+R, DVD-RW and DVD+RW standards. Although some falsely claim that these overlapping standards have confused consumers, it is clear that having these multiple formats has given manufacturers ample opportunity for upselling multi-format DVD players and burners. With a single format, where is the upsell? Ecma clearly understands the purpose of standards and can be relied upon.

Once you are in an SDO and are ready to create your Technical Committee, be sure to carefully consider the topics of membership and charter. Of course, you’ll want to assemble a team of willing partners. Loyalty can be obtained in many ways. Your consigliari may have some ideas.

You charter is your first line of defense. Since your Technical Committee may contain some technical people, you will want to strictly limit what they discuss. Technical people are dangerous if they are given too much freedom. Who knows what they may do if left on their own? They might even innovate (shudder), and innovation is so disruptive. A well-written Charter can prevent innovation, that unwelcome guest, from ever knocking on your door.

Since its terms restricts the scope of your work, you should ensure that your charter contains any restrictions that you do not want to discuss or defend in the future. Best to get these front loaded into the charter so you can just say, “We have no choice; that is our Charter”. Your goal is to describe the One True Implementation, so a good charter restriction to add is one which will focus the technical committee on that one single task. A roundabout way of doing this is to require that the produced specification must remain 100% compatible with a different specification, one which is your secret. That way you, and only you, can decide whether or not a proposed change is within scope of the charter. This provides a lot of flexibility and avoids unnecessary discussions. “We checked the secret specification and it says that October has 40 days in it. Sorry guys, there is really nothing we can do. The Charter won’t let us.”

A few additional recommendations for the the day-to-day work of describing the One True Implementation:

  • Observe other successful standards and the process that lead to them. Look at the size of their specifications and how long it took to develop that. Assume that you can safely progress at a rate 10-20x faster. This pace is justified by the superiority of your One True Implementation and your lack of deliberations, discussions or considerations of alternatives.
  • At all costs avoid reusing any existing standards. Reuse of standards will only lead to generality, interoperability and increased reuse and risk getting you involved in discussions with other standards bodies. This delay must be avoided. The One True Implementation has everything you or anyone else needs to know. It is the true fons et origo of all wisdom and knowledge.
  • This also implies that you do not engage other standards groups. Assume that your hand-picked technical committee is an expert on everything. In any case, expertise is irrelevant, since you are merely describing the One True Implementation. All the decision making essentially already occurred years ago. Your task is just writing it down.
  • Secrecy is paramount. If the unwashed masses find out what you are discussing and what issues you face, they might do things like offer you suggestions or alternatives. That is so annoying. So all meetings, minutes, mailing lists, etc., should all be strictly private.

That’s about it. Eveything else is just common sense. Think Speed. Think Heft. Focus on the One True Implementation. I believe the liberal application of the above principles should enable anyone to quickly and painlessly create an International Standard.

  • Tweet

Filed Under: Standards Tagged With: Ecma, OOXML, Satire

The worm in the apple

2006/12/05 By Rob 3 Comments

Via CrunchGear, MacWorld UK, and APC Magazine — Mac Office users seem to have no way of reading the new OOXML files which Office 2007 for Windows writes by default. APC quotes a Microsoft Mac Business Unit spokeperson as saying, “Unfortunately it is still to early for us to say when the converters will be available”.

Whoops.

As a public service I note two alternatives: the Mac port in OpenOffice.org and NeoOffice.


9 December 2006 Update: Interesting analysis from from Andrew Shebanow over at Shebanation: How adding OOXML support to the Mac is likely 150 person-year effort. And Mary Jo Foley’s Unblinking Eye points out that the problem is not just with the Mac support. Windows Mobile 5.0 will lack OOXML support until mid-2007.

Is it just me, or does this seem like something less than a coordinated roll-out? The clean, hassle-free way of doing this, with the least suffering for users and admins, would have been like this: Ship Office 2007 with OOXML support, but not as the default. Then over the next year get the rest of the Office ecosystem working with OOXML: the Mac, Mobile, Sharepoint, Excel Live, etc. Get all of the support out there, but don’t force it on people yet as a default. When all the pieces are ready then, via a service pack or version upgrade, change the defaults. Everything goes smoothly from there.

The fact that they didn’t follow this roll-out model suggests that someone at Microsoft really, really, really wanted to get OOXML out fast, even if it wasn’t pretty.

Luckily admins do have the ability to perform a more orderly roll-out in their organizations if they wish. The default format for Office applications can be changed via a registry entry. For example, for Excel the registry entry is:

HKCU\Software\Microsoft\Office\12.0\Excel\Options\DefaultFormat

By default it isn’t there, but you can create an entry of type REG_DWORD and assign it the value of 56 (38 hexadecimal). Once you’ve made that change, Excel documents will be saved in the legacy binary formats by default. Similar registry settings for Word and PowerPoint are:

HKCU\Software\Microsoft\Office\12.0\Word\Options\DefaultFormat

create REG_SZ with value of “Doc”

and

HKCU\Software\Microsoft\Office\12.0\PowerPoint\Options\DefaultFormat

create REG_DWORD with value of 0

It should be trivial for someone with a Windows compiler to create a simple application to accomplish this same task. Ideally it would also allow the default to be changed to any other format of the admin’s choice, including turning it back to OOXML if/when admins desire to deploy that way, or changing it to ODF when a good Plugin is available.

10 December 2006 Update: My attention has been drawn to an earlier post from a lead in Microsoft’s Mac Business Unit, where the removal of support for Visual Basic macros is discussed. Damn, that’s cold. Ever get the feeling you’ve been marked for extermination?

17 May 2007 Update: From News.com “Microsoft delays Office convertors for Mac” and some great follow-up analysis by Andrew Shebanow over at Shebanation.

30 May 2007 Update: More analysis and commentary on this ongoing issue from Joe Wilcox over at Microsoft Watch:

Meanwhile, Microsoft makes big noise about interoperability. What kind of example does Microsoft set when the formats for its Mac and Windows Office suites aren’t interoperable? Irreconcilable is the position of increased Microsoft-and-other platform interoperability and the decreased interoperability between Office file formats across two platforms.

  • Tweet

Filed Under: OOXML

  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Interim pages omitted …
  • Go to page 10
  • Go to Next Page »

Primary Sidebar

Copyright © 2006-2023 Rob Weir · Site Policies