An Antic Disposition

October is almost here. The last quarter. This is the time of year I start thinking of next April 15th and what I can do this year to reduce my taxes via by recognizing some capital losses, making charitable contributions, etc. It also makes me think about taxes in general and how much the tax filing process has changed over the years.

I've been a taxpayer in Massachusetts since 1988 or so. At first I filled via paper returns. This invariably involved started with a trip to the Post Office or Library to pick through the stacks of forms to find the ones I needed, and then to make a return trip the next day when I found out that I missed a schedule. I would typically get two copies of everything: one to do the draft work in, and one to file. Quantum Electrodynamics, the music of Arnold Schoenberg, James Joyce's Ulysses -- these were all easy and made sense compared to doing taxes.

Sure, I could have just carted my paperwork off to an accountant and let him deal with the mess. But I'm opposed to that in principle. Taxes are paid by everyone and everyone should be able to do their taxes. Something is wrong with the tax system, democracy, or both if a Harvard grad is not able to figure out his own taxes. But sometimes it was a struggle.

Eventually, in the mid 1990's (my recollection) the Massachusetts Department of Revenue (DOR) started to support online filing. Initially this was via a proprietary, state-issued, Windows-only client that worked with a dial-up modem connection. It was advanced for the time, but still bare bones, and clunky. I actually still did most of the form by hand, and entered in the numbers into the UI for the final calculations and submission.

Things got interesting a few years ago when the DOR stopped issuing their own client. Instead they promulgated standards for on-line tax submission, issued developer guidelines, a compliance test suite and started certifying vendors who wished to write compatible tax filing software. You can see the software guidelines here.

Now, there are some that say that government mandated standards are evil, that they stifle innovation, remove choice, hurt the consumer, etc.

[G]overnments should not freeze innovation by mandating use of specific technology standards
-- Policy statement from Microsoft's "Freedom to Innovate" network

So it is interesting to see what happened in Massachusetts after they issued standards in this area.

Today, Massachusetts residents have a choice of 11 applications for filing their state income taxes, at all price points. These range from free filing for qualified low-income residents, to low-cost web-based applications for simple returns, to rich client-side solutions for more complicated filings. The full list of compliant filing software is here.

So, in this case, the state-mandated standard did not lead to lack of competition or innovation, but rather led to a thriving market of filing solutions, at a variety of price points and feature sets. The tax-paying public benefited with increased choice of products and feature sets. The DOR benefited with returns that could be processed at lower cost and lower error rates. And software vendors benefited by the creation of a new market in tax preparation software.

This lesson is something to bring to mind the next time you hear the contrary FUD about standards and innovation.

Labels: Massachusetts, ODF, Standards, taxes

I recently gave a presentation where, in passing, I enumerated a variety of usage patterns for ODF, demonstrating that it had wide applicability beyond the traditional heavy-weight office-like editors. This diversion in the presentation was well-received then, so I offer you a fuller version of these points in blog form.

1. Interactive creation in an a heavy-weight client application. This is the traditional mode of operation in KOffice, OpenOffice.org, etc.
   
2. Interactive creation in a light-weight web-based application. We are starting to see this at Google with Writely and Google Spreadsheets.
   
3. Collaborative (multi-author) editing. This includes the traditional "comment and merge" style of collaboration as well as real-time, multi-user editing, where multiple authors edit the same document at the same time.
   
4. Automatic creation of document in response to a database query. This is the report generation model of use. Data source could be a web service rather than a database.
   
5. Indexing/scanning of document for search engine.
   
6. Scanning by anti-virus.
   
7. Other types of scanning, perhaps for regulatory compliance, legal or forensic purposes.
8. Validation of document, to specifications, house style guidelines, accessibility best practices, etc. So, beyond RELAX NG validation, beyond Schematron, into content validation that is beyond XML structure.
   
9. Read-only display of document on machine without the full editor, for example a light weight viewer as a browser plugin or extension.
   
10. Conversion of document from one editable format to another, i.e., convert ODF to OOXML.
    
11. Conversion of document into a presentation format, such as PDF, PS, print or fax
12. Rendering of a document via other modes such as sound or video (speech synthesis)
13. Reduction/simplification of document to render on a sub-desktop device such as cell phone or PDA.
14. Import of ODF into a non-office application, i.e., import of spreadsheet data into statistical analysis software.
15. Export from a non-office application into ODF, such as an export of a spreadsheet from a personal finance application.
16. An application which takes an existing document and outputs a modified version of that presentation, e.g., fills out a template, translates the language, etc. This has some nice benefits since it allows separation of concerns, where a business user can control the look of the document, but leave place holders that can be filled in by automation, perhaps based on a web service query.
    
17. Adds or verify digital signatures on a document in order to control access (DRM)
18. Software which uses documents as part of a workflow, but treats the document as a black box, or perhaps is aware of only basic metadata. This is the way most current systems work.
    
19. Software which treats documents as part of a workflow, but is able to introspect the document and make decisions based on the content. This relies on the transparency of the ODF format, and the ability for software to see what is inside.
    
20. Software which packs/unpacks a document into relational database form, i.e. XML-relational mapping.

I am interested in other patterns of use you might have, especially ones that do not overlap the above.

The exercise of producing the above list made it clear in my mind that many of these items should be given more consideration than they traditionally have. For every document created in a heavy or lightweight editor, there may be many other much smaller applications which will need to read the document down the road.

By analogy, this blog entry was created an editor, but the number of readers, indexers, aggregators, etc., that will touch it in downstream processing will far exceed, in number and processing cycles, the effort spent in writing it. So ease of processing, especially ease of reading, is an important consideration for designing and evaluating an XML document format.

Labels: ODF

As mentioned in a previous post, OASIS and the ODF Adoption TC have set up a web site at http://opendocument.xml.org to act as central resource and repository for ODF information, as well as to be a focal point for the ODF Community to discuss items of importance.

I've just contributed my first item there, an essay/proposal about something I've been thinking about for a long time now -- how to make application developers love ODF. I call it an Open Document Developers Kit (ODDK). You can read the proposal here. Please direct any comments to this discussion thread at XML.org.

It was a good year for my berries. I have a 400 square-foot "berry patch", half of it for the Fragaria genus (Strawberries, Alpine Strawberries, Musk Strawberries) and half for the Rubus genus (Raspberries, Blackberries, Thimbleberries and the various crosses such as the Tayberry and Loganberry).

The strawberry harvest in June went well in spite of the unusually persistent wet weather we had in May. I normally try to garden organically, but with that amount of moisture coming after bloom, the conditions for Botrytis (grey mold) were too good, so I had to spray a couple times with Captan. In the end we had far more berries than we could eat, so I was able to take 10 pounds of fresh berries and made a few gallons of wine. This is cellaring now, along with the raspberry mead I started last fall, and a gallon of an herbal wine (spearmint, pepermint and lemon balm in a 2:2:1 ratio). I've never made an herbal wine before and the ingredients were improvised based on what had a pleasing smell in the herb garden at the time. So there is a non-zero chance that I will end up with a gallon of homemade mint mouthwash.

I've been picking the raspberries for around a month now. I have the usual red varieties as well as some yellow and black. My wife refuses to sacrifice any of these to my wine making exploits this year. I will comply with her wishes, but I do hope to be rewarded with a pie in return for my benevolance.

Last year I started another bed, this dedicated to members of the Vaccinium genus (Highbush Blueberries, Wild Lowbush Blueberries, Bilberries, Cranberries, Lingonberries and Everygreen Huckleberries). These all share a common need for acidic soil, so it makes sense to group them together. Since this bed is only a year old, the fruiting was negligible.

I'd love also to plant some Ribes genus plants (Gooseberries, Currants) but these are illegal to grow in Massachusetts. This is an argicultural restriction put in place back in the 1920's to prevent the spread of Pine Blister Rust, a serious and deadly disease of White Pines. The organism that causes Blister Rust does not spread directly from Pine tree to Pine tree but only via the intermediary of a Gooseberry or Currant plant where it completes part of its lifecycle. So when the government wanted to eliminate Blister Rust, they banned Ribes and so I have no Currants.

I also have various other berries and small fruit that don't fall into the above categories, including:

• A Medlar tree
  
• A Pin Cherry tree (hope to make some wine from the fruit this year)
• Grapes (American Vitis labrusca "Fox" grapes, like Concord, Mars and Remailly)
• Serviceberry
• Honeyberry (Lonicera Kamchatika -- native to Siberia)
• Elderberry
  

Some good sources of berry plants that I've used include Nourse Farms here in Massachusetts and Raintree Nursery in Washington state.

Good books for the home berry grower include:

• The Backyard Berry Book by Stella Otto
• The Berry Grower's Companion by Barbara Bowling
• Uncommon Fruits for Every Garden by Lee Reich

For New England growers, a subscription to the UMass Berry Notes newsletter is a must. Although it is targetted to the commercial grower, most of the information is applicable to the home grower as well.

Labels: Berries, Gardening, Wine

I'm back from the OpenOffice.org conference in Lyon. Unfortunately, I was able to catch only the last 1.5 days of the conference, but from what I saw the sessions were informative, the hallway conversations illuminating, and the hospitality superb. I participated in a roundtable panel on "OpenDocument, Open Revolution" and gave a presentation later that day with the exciting title, "A Technical Comparison -- ISO/IEC 26300 vs. Microsoft Office Open XML (Ecma International TC45 OOXML WD 1.3)". The streaming media for these and other sessions are provided online by Kiberpipa.

I'd like to especially draw attention to John McCreesh's "why.openoffice.org" talk. Usually my eyes glaze over at "marketing" talks. But even with jet lag and loss of a night's sleep I found this to be an engaging and compelling statement of the OpenOffice.org value proposition.

A noteworthy item announced at the conference was the opening of an OpenDocument-focused web site at XML.org (http://opendocument.xml.org/). This is the "official community gathering place and information resource " for the OASIS ODF TC and ODF Adoption TC, and is a great place to go with questions about ODF and browse the content there. I encourage you to make it a regulary visit in your browsing habit, or sign up for one of the feeds.

Next stop: OpenDocument Day at the KDE Akademy in Dublin next Tuesday. I'm going to give a lighting talk on "A Standard ODF Object Model". I also plan to buttonhole everyone I see and try to convince them of the need for a unified effort to make an OpenDocument Developer Kit (ODDK).

Labels: ODF

Just saw something worth noting. I was on a machine running Office XP and tried to open an Office Open XML (OOXML) formatted document. I don't know why I tried that, but I did.

Word was smart enough to put up the following dialog:



Now, that is something I hadn't seen before. I think we all knew that Microsoft was planning a compatibility pack for enabling OOXML on Office 2003 and Office XP. But my 2002 version of Windows XP knows about OOXML? I guess this wisdom must have come down in a previously downloaded Office patch.

In any case, if you click yes, you are directed to this page where you are offered a download of "Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats (Beta 2)". I had the pre-req's, which included Windows XP SP2 and Office XP SP 3. So downloading a few file conversion filters should be simple and small, right?

Well, simple, but not so small. I was suprised to see that the convertors download was 43MB. That seems a bit large. In comparison, you can download a complete copy of OpenOffice.org, with included support for ODF documents and the Office binary formats, and the entire product is only a 93MB download. The 0.2 ODF Add-in for Word is only 1MB in size. So why does adding OOXML support to Office XP require a 43MB download?

In any case, once it is downloaded and installed, the integration with Office appears seemless. You can open OOXML files from the Windows Explorer by double-clicking on them, you can browse and load them as expected from the File Open dialog in Office, you can re-save files in OOXML format via the File Save, you can create a new document and save it as OOXML, you can even configure Word XP so the OOXML formats are the default format for all saved documents in Word. In fact, you can do all of those things that the Microsoft-supported ODF Add-in is not doing.

As reported earlier, the Microsoft support for ODF puts this ISO standard at a distinct disadvantage, providing no shell integration, removing it from its expected place in the File/Open and File/Save menus, and preventing users from making it the default format in Office.

So, let's update the file format support matrix:

Criterion	DOC Format in OpenOffice	ODF Format in Word 2007	OOXML Format in Word XP
1. Format supported in default install	Yes.	No. Requires a download and install of separate, unsupported Add-in.	No, but you are prompted to download a free converter pack the first time you attempt to open an OOXML file
2. File Open integration	Yes.	No. ODF is not listed in the default File Open dialog and doing a Control-O will not show ODF documents. However, ODF import is available in a separate menu item elsewhere in the menu system.	Yes.
3. Save new document integration	Yes.	No. In fact no ODF save ability exists in the current version of the Add-in. There is a place holder for the ODF save operation, though it is on its own menu, and would not be shown when doing a simple Control-S to save a new document.	Yes.
4. Can be made the default format	Yes.	No. Although other non-Microsoft formats, such as "Plain Text" can be made the default format, ODF cannot.	Yes.
5. Simple round-tripping	Yes.	No. When an ODF document is loaded, its name is automatically changed and it is made read-only. So loading sampler.odt results in Word having a read-only version of sampler_tmp.docx. Attempting a simple Control-S to save will give an error.	Yes.
6. Shell integration	Yes.	No.	Yes.

I tip my hat to Microsoft for the way they have provided OOXML support in earlier versions of Office. Aside from the size of the download, the process was simple and the integration was seamless. That's the way it should be. But what makes them think that customers using ODF format would want anything less than this? That fact that they've been able to integrate OOXML so well only increases the shame in having integrated ODF so poorly.

Labels: ODF, Office, OOXML

An updated version of the Microsoft-sponsered ODF Add-in for Word has been posted. A few weeks ago I had tried out the earlier 0.1 version with results you can read here and here.

The Add-in's Highlights page for the 0.2 version says that "This release is comprehensive with respect to Text, Formatting, Paragraphs, Images, Styles & document metadata scenarios".

So, I gave it a try, installing it with Office 2007 beta 2 running on Windows XP. Here's a summary of what I saw.

The UI integration I previously described and criticized remains unchanged. This will put ODF documents at a disadvantage not only compared to Word's native format, but also compared to other export formats suported by Word such as RTF or even plain text. The only other format that will be ostracized from the File Open menu like this is PDF, and that seems to be because of legal squabbling with Adobe. But what did ODF users do to deserve this treatment?

I tested a conversion with my sampler.odt file. This is a one-page ODF document that uses a combination of essential word processor features. It is not intended to be an acid test. Unfortunately the 0.2 Add-in failed to load the document at all, hanging with the winword.exe process spinning at 100% CPU. So there appears to be some sort of infinite looping going on.

I tried a few variations of this sample.odt document, removing page elements until I could get it to load without hanging. It appears that the image with the caption may be the source of the problem. I've reported this defect to the project's bug tracker and will try again when I hear that it is fixed.

Labels: ODF, Office, OOXML

Above you have Scott #1082, with a first day issue of exactly 50 years ago, September 3rd, 1956. The design is by Victor S. McCloskey, Jr. of the Bureau of Engraving and Printing based on a a small portion of a much larger mosaic, "Labor is Life" (also shown above) by the American artist Lumen Martin Winter. This mosaic was unveiled in 1956 by President Eisenhower at the the AFL/CIO Headquarters in Washington DC .

What a difference 50 years makes! One could write at length about how this stamp portrays a quintessentially 1950's view of the family, the status of women, the industrial base of American labor combined with the influence of depression-era socialist realist art. But it is Labor Day, so I suggest you all get off the computer and start up the grill. That's what I'm going to do.