The Next Stage in Composition -- McIlroy

As XML adoption becomes more widespread across all industries, there's an increasing focus on how to get XML-tagged content beyond the Web and into print. A recent W3C standard, XSL-FO, is an attempt to add formatting capabilities to XML, an attempt to add print formatting to data that was more likely intended primarily for electronic distribution, Web or otherwise.

Imagine how tough it would be if your father was SGML, and your mother was the anarchy of the Internet! What a difficult time you would have trying to find your real purpose in life.

Someone asked me the other day: "Does anyone really think about XML in the context of SGML anymore?" Well they should, because that's clearly where it came from. XML is a pared-down version of SGML.

According to the official 1.0 XML spec, "The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML."

Family of Standards

As a clear descendent of SGML, XML might logically be thought to be primarily involved with documents and their expression. XSL was one of the original three XML standards. Where did things go wrong? With all of the energy of the Internet and the Web, and all of the mad greed of the late 1990s, before we knew it XML suddenly became primarily an enabler of commercial data transactions. It hardly seemed worth the trouble of expressing this data visually.

Eventually the limitations of HTML began to nag, and Cascading Style Sheets were dropped into the pot to improve graphic expression (on the Web) including that of XML-tagged data.

But still nothing to do with print. I remember clearly at Seybold Seminars in the late '90s I would ask Web CMS and system vendors if they had any print options. The quizzical look I got back said it clearly: "Why would you want to do that?"

Fortunately some concerned participants in the W3C thought that it might be a good idea to make it possible to create professional-level print from XML-tagged data.

Perhaps the best source of information for the thinking behind XSL-FO comes from a fine article written by Stephen Deach for The Seybold Reports ("What is XSL-FO and When Should I Use It," Vol. 2, No. 17, December 9, 2002). He points to three problems that the XSL Working Group faced:

1) There was no language to describe the pagination of complex documents on the Web.

2) There was no way to deal with long documents and complex layouts.

3) The typography in CSS had been designed for browsers, not for print.

Data Conversion Laboratory, in its Website glossary, writes: "XSL. . . is a stylesheet language that gives us the ability to specify how data coded with XML will format on-screen (emphasis added). This language was developed based on the ISO companion standard for SGML known as DSSSL. . ."

On-screen? What could they possibly mean "on-screen"? That's not what XSL is about. Or is it? As Deach describes in the cross-media objectives: "XSL should cover the basic presentation requirements for. . . a wide range of display devices, including reflow or repagination for palmtop devices, and for the accessibility requirements that are now mandated by many governments."

Therein lays another example of this schizophrenia involving all things XML. Is the prime purpose print, or is it electronic presentation? OK, it's both. So can one standardized approach really address the cross-media challenge? Or will it meet the same fate as every other product or system that claims to handle cross-media? Failure. Adobe itself in the latest version of InDesign essentially admits that the cross-media dream had not worked out as previously expected. The cross-media feature of In-Design CS is to bundle up all the print text and graphics and ship them over to GoLive, a Web publishing application.

By all accounts XSL-FO can be considered a robust system, at least for technical documents. There's very little information out there yet on what works best, and what doesn't really work.

Probably the most detailed paper around is Eliot Kimber of ISOGEN International's presentation, "Using XSL Formatting Objects for Production-Quality Document Printing," offered at XML 2002 in Baltimore. As Kimber points out, "XSL Formatting Objects have unavoidable limitations from two principal causes: missing layout features and the limitations inherent in the two-step XMLxt-pages processing model." He says also that FO is "not a full solution for index generation." (Although this is addressed in the 1.1 version recommendations.)

Kimber, while generally very much on XSL's side, points also to a range of specific limitations, including an inability to deal with:

* Text that flows around arbitrary curved areas (but text flowing around rectangular areas is possible using side floats). There are no extensions that satisfy this requirement.

* Page-location-sensitive inclusion or exclusion of content. For example, there is no direct way to condition the text of a cross reference based on whether or not the target of the reference occurs on the same page as the reference itself. There are no extensions that satisfy this requirement.

* Any other presentation tuning semantics that require feedback.

Ken Holman echoes Kimber's theme when he writes, "Unfortunately there are many 'common' requirements that just couldn't be met with XSL-FO 1.0 that will be addressed in future versions. I understand that had the committee tried to add everything in the first version, it would never have been released due to feature creep. The first version was necessary to understand how it was going to be used." (The recommendations for version 1.1 were published in mid-December, but appear to be more of a "bug fix" for 1.0, than a new version.)

Easy Style Sheets

Eliot Kimber of ISOGEN is a supporter, and says that…"creating an XSLT- and FO-based style sheet requires about one half the effort of creating the equivalent style sheet in a proprietary system. In addition, the incremental cost of adding new document types or new layouts to an existing family of document types or layouts goes down over time as you refine your XSLT code to be more modular, making it easier to add new functionality or new input or output choices. No other SGML- or XML-based composition system has this characteristic."

Adobe's Steven Deach suggests that XSL-FO could be best for documents such as financial-planning guides, owner and maintenance manuals, and legal agreements and contracts. It's difficult to see why anyone would embrace the complexity of FO for these technically straightforward applications, much less abandon a current system (of which there are many) in favor of FO.

As far as I can determine, the use of XSL-FO today is limited in the extreme. The sense I get from the several FO mail lists (including XSL-List@lists.mulberrytech.com, http://groups.yahoo.com/group/XSL-FO/, http://forum.java.sun.com/-forum.jsp?forum=34 and www-xsl-fo@w3.org) is that there are few users, and that those few users are either in early testing mode, or undertaking compositionally simple documents, such as forms. I know of a few publishers experimenting with FO pagination. I've seen little mention of cross-media applications.

There's little general knowledge to be gained from these mail lists, and not much sense that delaying an FO implementation will leave you very far behind the crowd.

Arguably the biggest potential for FO today is just creating better print output from Web browsers. As G. Ken Holman points out in his XSL-FO tutorial, "We often take the printed form of information for granted, yet how many of us are satisfied with the print-screen functionality from a Web browser? How many times have you printed a lengthy Web document and found the paginated result to be as easily navigated as the electronic original?. . . When we want to produce a paginated presentation of our XML information, we necessarily must offer a different set of navigation tools to the consumers of our documents. These navigational aids have been honed since bound books have been used: headers, footers, page numbers and page number citations are some of the characteristics of printed pages we use to find our way around a collection of fixed-sized folios of information."

Nearly all of the XSL-FO renders offer print output via PDF. It seems odd at first—why PDF? But what alternative? QuarkXPress native format? OEB (Open e-Book)? PostScript? No, PDF is the logical format. It's well-structured (much more so than PostScript), and well-documented (the 1,172 page PDF Reference for PDF 1.5 can be downloaded without charge from Adobe's Website).

Though controlled by Adobe, no one is prevented from using it (nor required to pay a royalty for doing so.) It's the ultimate page-oriented print format, and a completely natural output file format for XSL-FO documents.

OK for Third Parties

Adobe has embraced this FO-PDF workflow, and broadly endorses it for third parties. I don't know whether to read this as a win for PDF or as Custer's Last Stand. In my view Adobe continues to struggle to find a clear role for PDF in an XML world.

Encompassing XML within PDF seems natural until you question the bottom-line benefits. Is the XML document provider more fortunate to have PDF to represent document appearance, or is the PDF user more fortunate to have the granular markup provided through XML? There has been a multi-year movement within both the XML and PDF communities to support the proposition of PDF and XML, rather than PDF or XML.

I remain unconvinced.

However I think that the question of the importance of XSL is perhaps more so related to the question of the ultimate importance of XML.

The key value of XSL is that it's contained within the family of XML specifications, and adheres to the XML syntax. As such, it is potentially able to offer two advantages that were never available to SGML. The first is the innate ability to tie the appearance aspects of the publishing process with the workflow and commercial aspects of the processes, in a single data stream. Standards like JDF, AdML and NewsML arose during the XML era, not the SGML era, and promise enormous workflow and business benefits.

Another great advantage is that elusive Holy Grail, a process to automate cross-media publishing. There is certainly a lot of work to be done, but I have no doubt that it's well within the capacity of XML semantics and XML engineering to build a basis for that workflow. The cross-media promise of XSL is real, if nowhere near realization.

But most significantly, XSL-FO will catch on because the adoption of XML (and, more importantly, XSLT) has become so widely entrenched across all industries, and has the unequivocal support of all of the largest and most important vendors across the business process landscape.

Working with XSLT moves a developer a big step closer to being able to implement FO, and that's a significant undercurrent of experience and energy propelling the standard forward.

The publishing industry has demonstrated repeatedly that it will favor standards over proprietary approaches, provided the software functionality related to the standard meets its business needs. As the XSL spec continues to mature, and as the software supporting it becomes more robust and user-friendly, I think we'll have a winner on our hands.

An altered and expanded version of this article appeared in the Gilbane Report, February issue.

—Thad McIlroy

About the Author

Thad McIlroy is an electronic publishing consultant and analyst, based at Arcadia House in San Francisco. He welcomes your comments at thad@arcadiahouse.com.