Be liberal in what you accept, and conservative in what you send.

Postel’s Law (aka “Robustness Principle”), as phrased in IETF RFC 1122.

Once a fatal error is detected, however, the processor MUST NOT continue normal processing (i.e., it MUST NOT continue to pass character data and information about the document’s logical structure to the application in the normal way).

XML Recommendation, World Wide Web Consortium (W3C)

The first is a respected axiom of programming and messaging design. Web browsers have always adhered to this principle. While the tolerance of Web browsers has infuriated HTML purists and frustrated Web developers, that same tolerance has been directly responsible for the astonishing popularity of the World Wide Web.

The second is an intentional design decision by the W3C committee that created XML back in 1998. Known colloquially as “draconian error handling,” an application that parses XML (including, for example, a Web browser that validates XHTML markup), is required to cease processing when encountering an error condition in the XML markup. Abort. Full stop. Don’t even try to display the broken Web page.

If Tim Berners-Lee had specified the draconian error handling of XML when he first created the HTML language, the World Wide Web would not exist as we know it today. You would be aware of it, you would probably know people who use it; you would perhaps likely use it yourself. But it would not be the global resource with billions of pages of content, globally accessible on a variety of devices, and forming a major component of our daily lives.

The W3C has acknowledged that XML may not be appropriate as a distribution format. The W3C has ceased the activities of the XHTML Working Group, and has focused its efforts on HTML5.

Does this mean anything more generally for XML? I hope so. I believe there has become a general awareness in the XML community that draconian error handling may not be appropriate in many circumstances. XML processing applications, by definition, ignore the staid “robustness principle.” And it shows. XML processing applications with which I’ve worked are anything but robust. Quite brittle, in fact. And this is an ongoing problem for any organization that attempts to deploy XML-based publishing.

{ 0 comments }

Leximation, Inc. has announced that the DITA-FMx 1.1 plug-in has been released. This plug-in improves upon the DITA support provided with Adobe FrameMaker 8 and FrameMaker9, including increased coverage of the DITA 1.1 specification and improvements to the authoring experience.

The DITA specification presents rather steep challenges to tool implementers. The Leximation plug-in further enhances FrameMaker as an option for DITA authoring and publishing. Given the complexities of XSL-FO for generating PDF output, and the recent uncertainty regarding PDF support in the DITA Open Toolkit, FrameMaker should be especially appealing for organizations that need high-quality PDF output from DITA.

{ 0 comments }

Some users of FrameMaker on Windows XP and Vista (including myself) have been vexed by FrameMaker crashes while generating PDF files, and generated PDF files with missing text (not good). The problem appeared to be random, affecting some systems but not others, and some documents but not others.

The workaround (until now) has been to delete the file “C:\WINDOWS\system32\FNTCACHE.DAT” and reboot. Many FrameMaker users would delete this file regularly, and some did so automatically through a shutdown script.

Mahesh Gupta, Product Manager for Adobe FrameMaker, reports that Microsoft has patched the underlying font management issues that have caused these problems. His post in the Adobe Technical Communication blog provides details of the Microsoft patch.

And there was much rejoicing among FrameMaker users!

{ 0 comments }

In the late 1980′s, I had a work-study job as a computer operator in the School of Computer Science at Carnegie Mellon University (B.S.E.E. 1987, M.A. 1989). That meant keeping the systems operating and loading backup tapes. Lots of backup tapes. One of the projects I supported was a speech recognition effort led by a Carnegie Mellon PhD graduate and assistant professor named Kai-Fu Lee.

Shortly thereafter, I took a staff position there in the research documents group, which was tasked with telling the U.S. Government (primarily DARPA) what we accomplished by spending their money. Again, Dr. Kai-Fu Lee’s project was among those that I supported.

Twenty years later, I find myself in Beijing at the WWW2008 conference, in the audience at the opening keynote, delivered by Dr. Kai-Fu Lee (now Vice President of Engineering at Google). I think it says something about my career that I’m now half-way around the world, attending a keynote by Dr. Lee. Exactly what it says, I’m not sure.

Dr. Kai-Fu Lee at WWW2008

{ 0 comments }

Last week I had the privilege of representing the Society for Technical Communication at the semi-annual meeting of the World Wide Web Consortium (W3C) Advisory Committee, this time in Beijing. As a W3C member, the STC participates in W3C governance. Perhaps more importantly, the STC can place members in W3C member-only roles, like participation in W3C working groups. There is substantial interest by the W3C in increasing the participation and support of the STC in its standards development and communication activities.

The W3C is working on standards in several important and exciting areas, including accessibility, mobile devices, the next generation of HTML, and the next generation of the Web itself, the Semantic Web. Leaders from each of these areas are interested in support for drafting specification documents (the W3C calls them Recommendations), and for writing and editing supporting documents to explain W3C Recommendations to appropriate audiences.

More on that later. Until then, a picture (me at the Great Wall, Mutianyu section):

Alan Houser at Great Wall

{ 0 comments }