Gah. Looking at the source version of the document (MS Word, naturally; /usr/bin/file says it's an OLE 2 Compound Document), it looks like the dominant font used is Tw Cen MT, which is available with Microsoft Publisher or some other silly MS upsells, or can be purchased separately for a 5-seat license for $112.

Their "Key Recommendations" section says:

As a result of the study, the workgroup developed the following recommendations to ensure the State's electronic records are:

• Created and preserved in ways that encourage choice, interoperability, and vendor neutrality;
• Accessible to the public; and
• Kept under proposed appropriate government control.

What part of "Accessible to the public" does a $112 font play into? How does using a font licensable only from one company "encourage vendor neutrality?" Someone who only bought the basic MS Office would have trouble viewing that .doc file in the intended way. And though most of the other fonts used in the document are offered by Microsoft at no cost, there's not a single truly free font (in the OFL sense) in any of them, from what i can tell.

Their summary says:

The State needs open standards and formats. Simultaneously, the State needs electronic records to be preserved in their original formats whenever possible.

Wouldn't it follow, then, to create the documents in an open format (using only fonts and other embedded information that are freely available) in the first place, so you could have both goals attained at once? This isn't rocket science here.

Other bits of dissonance between their publication choices and ostensible content of the report:

• Why are these reports not published as well-indexed and annotated html, to allow for simple deep linking to particular sections, comments, and observations by the public? Wouldn't that be more accessible, and foster public commentary and engagement?
• Why don't their published PDF files contain embedded indexes for easier navigation? If i import the .doc into OpenOffice.org and export PDF, i automatically get a navigable index in the sidebar if i view that PDF with evince. No such index is available with their MS/Adobe-created PDFs. If the goal is accessibility, why not build in the index for the documents that are dozens of pages long? Surely Acrobat Distiller is capable of representing the structure of the document...

OK, that's enough grumpiness for one evening. I'll go sleep it off.

Now that i've slept a bit, let me temper some of the above grumpiness a little bit with some more-upbeat observations from people i've talked to. My friend Ross Glover wrote:

My reading was a bit more positive. They claim that the state has already committed to an open format, so that's not even an issue. What is at issue is the relationship between NYS and the business world. The clear recommendation is to inform vendors that one of the state's primary concerns is with openness and supporting open formats. They also state that commitment to openness should be one of the key aspects in making decisions about contract bids. When the state says it's going to weigh it's decision to accept a contract bid on something as specific and relatively easy as format support, I think that's a pretty big step. From my reading, it seems like they opened the door for someone to come in and make a complete overhaul bid for open format support and it be taken seriously.

I would also argue that that the wishy-washiness of the report has more to do with user resistance than resistance from the reporting organization. For a state org., this distinction would be hugely important because of the amount of training required for such an endeavor. However, when the ERC comes into being, one of it's primary charges will be determining how to make openness a reality.

Finally, while they say the state shouldn't get into the debate about competing document formats, they say that "state policy issues and business needs should drive it's choices of technology tools." Since state policy is already dedicated to openness, they've already entered the debate and come down squarely against closed formats. Isn't that a pretty strong stance?

This is a pretty insightful read, and i'm glad he sent it in opposition to my admittedly negative interpretation. As a programmer, i'm usually looking for worst-case scenarios: if the code i write could go horribly awry in one or two really unlikely instances, it's something that needs to be fixed: for someone, somewhere, those instances will happen, and my software will screw them over.

But perhaps this approach to reading code (and documentation) isn't the best idea on public/gov't documents like this. Ross is right on more than a few points:

• There is a clear expression in the Summary that openness is a goal of the state. My dismissal of this is due partly to the way that "openness" has been used in counterpoint to "freedom" within the software world -- liberty for end users (or citizens, in the State's context) is the goal i'm interested in, and openness is a means to that goal. We've seen enough examples of hijacking corollary movements (e.g. so-called shared source and hijacking standards bodies to change the definition of "open") to make me want to see the good governance and citizen freedom aspects take the foreground, instead of investing in a corollary which has the potential to be corrupted.

  That said, it really is laudable for NY State to push explicitly for openness, even if "openness" itself can be slippery. Open Government is a Good Thing. I'm glad they're committing to it.

• We're not going to go from an MS-centric State to a Free State overnight. I want the changes to come as fast as possible, but i also want them to be sustainable. Ross' point about pushback due to training costs is worth keeping in mind, too. Given the clear technological hurdles the State faced from their entrenched MS toolset just to publish this report, we've got a long way to go (the ODF-formatted versions of the documents have now been published!). The report is at least a recognition of the problem, and in many ways, a call for help resolving it.

I was also contacted by John Cody from the NYS OFT, who was the Team Leader on the report. He sounds like a reasonable person (a good thing!), and seemed puzzled and frustrated by the disappointing review: he sees the report as a strong recommendation for openness, and a push to "figure out ways to get there". Even if it's not as strong a push as i would have liked, i'm happy that the folks preparing the report seem to have the right goals in mind. John pointed me to Bob Sutor's Blog post about the report, which contains some insightful stuff he extracted from the the supporting documentation. I hope to get a chance to read that section of the report this weekend.

So: i'm still disappointed and a little pessimistic, but less so than at my first reading. And it could certainly be worse: at least the State is asking these questions!

One more note (i'm sure it's terrible form to keep adding comments to my own post, but oh well):

While the ODF files are now published, it looks like the OFT's web server is issuing an invalid Content-Type for these documents. Here's a way to see the problem, and how to find the proper MIME type (thanks to the maintainers of the mime-support package for making this lookup so easy):

[0 dkg@squeak ~]$ wget -S 'http://www.oft.state.ny.us/policy/esra/erecords/PartIIerecordsStu dy.odt'  2>&1 | grep Content-Type
  Content-Type: .odt
[0 dkg@squeak ~]$ grep odt /etc/mime.types 
application/vnd.oasis.opendocument.text				odt
[0 dkg@squeak ~]$ 

Any OFT folks reading this who want to fix it: you should be able to configure new MIME types for IIS 6.0 through their GUI. (note: i've never used IIS before, never plan to, and this is the result of a brief google search: take with salt!)