ODF

A typical team project, whether software, standards, bridge construction or what have you, has a slow start dominated by a planning and scheduling, a middle period of execution, and an finish with final frantic rush of activity to complete the project. Then everyone takes a few days off and we start again.

One thing I learned early in my career was how wasteful this kind of project cycle is. The problem is that not everyone is involved in every part of the project. Some only work on planning, some only on execution, and some mainly come in at the end. This leads to suboptimal allocation of resources. People are standing around waiting.

One solution, not necessarily the only one, is to work on multiple versions of a project at once. For example, when working on a software application, you can take 25% of your team and have them start the planning phase of version N+1 while the remaining 75% of the team completes the final QA stage of version N.

We have a similar issue with standards development. Both the OASIS and the JTC1 PAS process involve a lot of standing around waiting: at least two months of public review in OASIS, and 6 months of review in JTC1. And even now, as we complete the editing work on ODF 1.2, the wider ODF community is standing around waiting. It is too late to make feature proposals for ODF 1.2, but too early for a full public review of the ODF 1.2 draft.

What is to be done?

The ODF TC has decided to begin activities on the next version of ODF, called for now “ODF-Next”, even before we have ODF 1.2 approved. Although we obviously won’t be spending a large amount of time on that effort quite yet, since we really are all busy with ODF 1.2, we have come up with a way to engage the broader community and have you help us gather requirements for ODF-Next now, which we can then consider during the downtime when ODF 1.2 is under review in OASIS and JTC1. The Call for Proposals for ODF-Next went out on Friday.

So put on your thinking cap. ODF 1.1 and ODF 1.2 were incremental releases. Maybe ODF-Next will be bolder, maybe something that shifts the paradigm, pushes the envelope, breaks out of the box. Is the dominant WYSIWYG word processing paradigm the final word in user productivity? Or are we overdue for a change, for a different set of priorities? As Thomas Paine wrote, “We have it in our power to begin the world over again.”

Now is the time to start collecting the ideas, big or small, and submit them to the ODF TC according to the instructions in the Call for Proposals linked to above.

We’ll be collecting ideas at least until March 31st. The Requirements Subcommittee will then sort through the ideas, categorize and prioritize them, and generally try to make sense of it all, and then write up an ODF-Next Requirements document with their recommendations.

This is a good chance to get your ideas in early and have a real impact on where we go with ODF in the next major release. But please, do not give me ideas via blog comments. We can only accept ideas sent through the above linked OASIS comment submission procedure, which is necessary to ensure that ODF remains an open standard that anyone can implement. IANAL, but I believe an added benefit is that any idea you submit, even if speculative, even if not added to ODF-Next, will be permanently archived in the ODF comment list, and thus will establish prior art which could scuttle attempts to secure patents in this area. So by contributing your ideas publicly in this way, you help to establish an intellectual commons that will benefit free and open source applications in this area.

Please pass along the word. We’re hoping to get 100’s of ideas for ODF-Next. Bring it on!

Back in the 1980’s, when I was a student, I was also an avid shortwave listener (SWL). This was in the days before the web, satellite TV or 24-hour international cable news coverage. I had an upper floor room in Cabot Hall, and each night I would surreptitiously dangle out the window a 40-foot wire antenna attached to a small weight.

At first I listened only to the big broadcasters like the BBC Word Service, Deutsche Welle, Radio Moscow, and then moved on to smaller ones: Tirana, Malta, South Africa, etc. It was a great way to get a global perspective beyond the 2-minutes allocated to international news on a typical US-based evening news program.

Eventually I started writing the broadcasters and received many QSL cards. Some of my letters were read on the air. I’m sure I ended up on some FBI watch list for those letters to Radio Prague and Radio Havana. My subscription to Soviet Life magazine, and a Cambridge address probably didn’t help either.

But you don’t go far as a SWL before you notice that there are a lot of strange things going on in the aether. Some were easily explained — the Soviet Union jamming broadcasts of Voice of America or Cuba jamming broadcasts of Radio Martí. And then there were the commercial voice broadcasts, ship-to-shore, international aviation, time signals, etc. Then the various data services, radio teletype, weather fax, etc. And then there were the mysterious coded transmissions, which we rumored to be SAC tranmissions, “Sky King, Sky King, Do not answer”, followed by various authentication codes, which were either recall or go ahead codes for nuclear attack. It was an eerie feeling, in the hotter days of the Cold War, to lay awake at night, listening to the radio and wondering whether the sun would rise in the morning. Now I just wonder if my 401(k) will still be there.

Stranger yet were the cryptic transmissions of the “numbers stations“, which would transmit on a semi-regular schedule and merely read off a large list of numbers for 10 minutes. For months I transcribed one particular woman’s transmissions, trying to find out the pattern. I did some computer analysis, but the numbers were random in frequency, with no discernible patterns. Presumably they were encoded against a one-time pad.

And then there were the “pirate” radio stations like “The Voice of the Purple Pumpkin”.

Although most people knew about the BBC World Service, I don’t think many appreciated that a large portion of the shortwave universe was strange, that the fringe was everywhere.

I’m starting to have a similar view of the web. Their are major content providers, minor content providers, even individual content providers like me. And then their is the weirdness, the strange corners of the web, the space between the channels, where you are not even sure you are listening to signal or noise.

Here are a few random examples of web sites with no discernible purpose. They appear to be garbled republications of new stories.

Let’s start with the “Wet Paint Body Notes” blog, newly created, with only three posts. One is called “Microsoft Gets Foot in Mass. Office Door“. It starts:

In what could be a coup inwardly favour of Microsoft (Nasdaq: MSFT) and a biff to the friendly wellspring league, the stipulate of Massachusetts personal added Microsoft’s Office Open XML norm to its document of give your declaration standards it will allow for elected representatives exploit.

This is a strange kind of English. It almost seems like a poor translation, or even a poor machine translation, of a document written in another language. But if you poke around a little, you find the this blog post is an unattributed garbled derivation of a 2007 article in Linux Insider. Not only was the original article in English, the reposted version truncates the article, posting only the first few paragraphs.

So what’s up with that? There are no banner ads or other obvious sources of revenue on the garbled version of the article. It is not a link farm. In fact it has no outgoing links. So why did someone bother?

Another example. The blog “75Software-News48” has an new article “Microsoft shows support for ODF“, posted just two weeks ago, with the intro:

Amid organization hassle surrounded by wish of interoperability, Microsoft (Nasdaq: MSFT) protected Thursday announced the discovery of the Open XML Translator Project. The overhang will fry in the air permitted software to allow Word, Excel and PowerPoint to knob documents in contrary technology format.

Again, this reads like it is a poor translation from another language. But look further and you can find that the original article is actually in English, from a 2006 TechNewsWorld article.

Again, no obvious intent here. It isn’t a link farm, and there is no evident source of revenue. It isn’t informative and it certainly isn’t timely. So why did they do it?

One more example this time a LiveJournal blog called “All Microsoft”, again newly created, with a post called “Ecma Approves MS Office Format, IBM Dissents“. It opens:

Microsoft’s (Nasdaq: MSFT) Open XML bureau software format, broad of via the tech giant to chase near the Open Document Format (ODF), cleared a standards hurdle this week, successful approbation from the Ecma global standards article.

Same modus operandi here. Original source, unattributed, is from a 2006 Linux Insider article.

I have dozens of examples of this kind of thing, all within the last couple of months, mainly articles about Microsoft and ODF. Something new is afoot. But what? Anyone have any idea of what this is and who benefits from it? If this just a contest between Blogger and LiveJournal to see who can claim the most hosted blogs? Or is it some SEO ploy? It has me stumped.

It is not the end of the end, nor the end of the beginning, but more like the beginning of the end for the development of ODF 1.2. The Committee Draft 01 of ODF 1.2, Part 1 was approved by the OASIS ODF TC yesterday in a 9-2-2 vote. You can download it here.

A Committee Draft (CD) is the first step toward finalizing ODF 1.2. The TC will likely approve further CD iterations before voting to approve one as a Public Review Draft. The Public Review Draft, as the name suggests, will be what we send out for a public review of at least 60 days. We can then make changes based on review comments and hold additional public reviews if we make non-trivial changes to the Public Review Draft. The ODF TC can then vote to approve the draft as a Committee Specification. We then hold a further vote to send the Committee Specification out for an OASIS-wide ballot (not just the ODF TC, but all OASIS members) on whether to approve ODF 1.2 an OASIS Standard. Once that is done, we can then start the PAS approval cycle in JTC1.

Although there are a lot of votes and process steps remaining, the major technical work is just about done. What remains is a period of review, perfecting the text, gaining implementation experience and feedback, etc. Some may call this a “death march”, but I see this pace as consonant with the importance of our activity and our deliverables. Work in OASIS might not be as fast as Ecma, where you can evidently create a 6,000 page standard in less than a year. Our process calls for a bit more than the IETF’s “rough consensus and running code.” But neither are we the slowest process in the standards development landscape. We’re some place in the middle. And when we’re talking about revising an open document format, already adopted and used by governments around the world, I am not ashamed to say that we’re working deliberately and carefully.

We also need to socialize and grow consensus around ODF 1.2, both from implementers, but also adopters and consumers of ODF. There is still work to be done here. For example, the TC vote on the Committee Draft 01 was not unanimous. We did not have the support of Microsoft or Novell. There are still disagreements over how we define conformance in the standard. We obviously need to continue discussing this topic. Since the final TC vote to request an OASIS Standard ballot requires 2/3 approval of TC members with no more than 25% disapproving, we’ll need a high level of consensus in the TC to move forward, including, hopefully, the support of Microsoft and Novell.

Implementation experience is important in OASIS. I know some have criticized OpenOffice for having support of draft ODF 1.2. But this support is a good thing, in my opinion. We need implementers to validate the design decisions we’ve made in the standard, to ensure that our choices are reasonable, that we haven’t missed anything. We’re working in an engineering discipline. We’re not making abstract standards for the mind alone. Engineers build, test and refine. It is what we do. In fact, OASIS requires that before a Committee Specification can be nominated for an OASIS Standard ballot, the TC must certify that there are three conforming implementations of the Committee Specification. So not only are early implementations a good idea, they are required as part of the process.

If you are asking, “How can I help?”, then here are a few ideas:

1. If you are an implementor of ODF 1.0 or ODF 1.1, then now is a good time to start looking at what is required to add ODF 1.2 support. Download the CD of ODF 1.2, but also look at this page for a summary of changes. We’ll formalize that list of changes and put it into a appendix of the draft, but this wiki page should give you a good feel for what areas have been touched.
2. Although we have not yet approved a Public Review Draft specifically for public review, we welcome comments at any time. You can send comments on ODF 1.2 CD 01 according to the instructions on this page. Download the draft, pick a chapter of interest and send us any errors you find.
3. We should start thinking ahead to how we can encourage a thorough review of the eventual Public Review Draft. I want to avoid the OOXML-fiasco where Ecma approved and sent to JTC1 a half-baked, deeply-flawed text. What can we do to give ODF 1.2 a really hard scrub in the OASIS review period, so what comes out meets the high standards we should expect from an international standard? I think we’ve done a good job in drafting ODF 1.2 and I want to encourage scrutiny, not shy from it. But let’s have this scrutiny earlier rather than later.

Back in 2006 I gave a short in talk at a KDE conference in Dublin on the topic of “A Standard ODF Object Model”, essentially laying out my thoughts on why we needed an “ODF Toolkit”. As part of that presentation I listed “20 Prototypical App Dev Scenarios”, my attempt to enumerate all the fundamental patterns of use for ODF. I did a blog post on this list later that year.

I’d like to augment that list with a new pattern of use, a clever idea suggested to me by Jomar Silva in an email quite a while ago, but an idea which I just recently warmed up to. I believe this technique could be quite powerful and should take its place as the 21st scenario for any ODF Toolkit.

It goes something like this:

If you have a toolkit written in a language, say Java, and the toolkit has API’s which you can use to both read and write ODF documents, then you can write a program that will read an ODF document and write out the Java code that would be needed to re-create that same ODF document. So it is a code generation pattern. Java code reads ODF and writes source code for Java program that can then be compiled to write ODF.

This is very useful in a number of situations. For example, you can design your document in a familiar tool, like your word processor. Get all of the styles and layout correct and then run the code generator to generate the Java source file. Then hand-edit the source code to make changes, such as substitutions, insertions, looping to copy content down a row, etc. You could even adopt a place-holder convention in your original document, to make it easier to find the areas that you wanted to replace. For example “REPLACE-FNAME” and “REPLACE-LNAME” might be be a good place-holder.

Of course, this idea is of general applicability, not just limited to ODF. It could be applied, and for all I know has been applied to HTML, etc.

I have a short ODF trio to share with you today.

First up, Jomar Silva brings us the happy news that Venezuela now mandates the use of ODF, joining Uraguay, Brazil and 14 other national governments that have adopted the International Standard for office documents.

BrowserShots.org has been part of my web design toolkit for some time now. It allows me to easily test a web page to see how it renders on a wide range of browsers and platforms, without having to personally maintain a dozen different machine and configurations on my desk. You enter a URL and click off which of 50+ different browser versions you want your page rendered on. The system then queues up your requests, farms them out to various machines that render the pages and return screen shot images (PNG format) of the results. You get some results almost immediately, while others might take 30 minutes.

I’ve recently received news that this same concept is now being applied to ODF documents in a new project called OfficeShots. Funded by the Dutch government and the OpenDoc Society, this project (not quite yet ready for beta) will:

[H]elp you make a better choice by letting you compare the output and other behavior of a wide variety of applications. Does your corporate style – the technical basis for many documents – actually look consistent across the board of applications – from OpenOffice.org 3.0, Adobe Buzzword and Symphony 1.2 to Microsoft Office 2000 with the ODF addin from Microsoft – or the one from Sun Microsystems? And how does it look on Mac OS X in iWork? When you are in an acquisition phase, officeshots.org will help you do a reality check if that fancy new open source suite or that productivity package you can get a bargain deal at – actually does what it says. On the spot.

This is a great idea and I look forward to seeing it in operation.

Finally, if you also have some ODF project ideas, then be sure to note that the NLnet Foundation has named ODF as one of its two focus areas for 2009 and that they are accepting project proposals for funding. So get out that digital pencil and start writing down ideas.