Having worked with SGML/XML formatting since 1992 and print/publishing technologies for decades, I have learned that choosing a formatting technology is not as simple as “standard is good, proprietary is bad.” As I explain in this paper, choosing a stylesheet language is a strategic decision requiring organizations to determine which technologies best meet their particular needs. As discussed in the following section, “Standard versus Proprietary” is not the issue.
Choosing a technology based on “Standard versus Proprietary” seems easy and logical, but keep in mind that a standard technology does not come with a guarantee of success. DSSSL, for example, is an approved ISO standard but a commercial failure.
In fact, a proprietary product may succeed while a comparable product based on standard technologies fails. Interleaf provides a cautionary tale. After Interleaf's purchase by BroadVision, the attempt at an XML/XSL-based product, BladeRunner, was short-lived while the original, proprietary, product lives on as QuickSilver.
Also, some proprietary languages, such as Adobe's PostScript and PDF, become de facto standards. Clearly, things just aren't as simple as “Standard versus Proprietary.”
XSL-FO and FOSI exemplify the situation. Both are official standards. Both have been implemented with proprietary extensions. FOSI is supported by two software vendors. XSL-FO is supported to one extent or another by several vendors and organizations. Development work on the FOSI standard has ceased while the XSL-FO standard is still in process.
This may sound to some like “XSL = Standard = Good, FOSI = Proprietary = Bad,” but there are other factors in the equation. In particular, you need to multiply by proprietary extensions and time.
XSL-FO is not an approved standard. Version 1.1 became a Recommendation in February 2006. XSLT, by comparison, has been a Recommendation since 1999. Over time, vendors have added many proprietary extensions to XSL-FO to open up existing features in their products, and they can be expected to add more extensions to win sales from those who believe non-proprietary is always better. As each vendor invests in implementing proprietary extensions, the XSL-FO standard will become more and more out-of-sync with existing technology. Integrating proprietary extensions into the standard will lengthen the standard approval process, inevitably leading to the need to create more proprietary extensions. This appears to be a vicious cycle with just one logical conclusion: XSL-FO will continue to become more and more proprietary.
At the current pace of standard development versus implementation, can the standard ever catch up with proprietary implementations? It probably doesn't matter much because “Standard versus Proprietary” is not the issue. The real issues are discussed in the following section.
If the goal is to best meet your organization's needs, the real issues to consider and questions to ask when considering stylesheet languages and available technologies are detailed below. With answers in hand, decisions should be easier to make and justify.
Data and text are as different as night and day. Data fits easily into fixed-length fields of an unambiguous type arranged in a specific order in a data structure. Text simply doesn't fit this model, so text processing has remained a mostly manual, interactive, process.
Structured markup, however, makes text more like data and therefore easier to process automatically. This includes batch, aka “lights-out,” formatting which is generally faster, easier, and cheaper than manual formatting.
Is your application for text or data? Text generally has more complex formatting requirements. Data may have a greater need for transformation.
SGML is more often associated with text publishing while XML is associated more with data applications. (Arbortext supports both plus Save As SGML/XML.) SGML and XML each have their strengths and weaknesses. Which better meets your organization's needs?
Formatting requirements can range from simple to complex. And the devil is very much in the details. To uncover requirements that may not be evident in a few printed samples, please see the Print Publishing Checklist at www.FOSIexpert.com/checklist.html.
Keep in mind that all formatting technology implementations have limitations, and that your current formatting may reflect various compromises. For example, with hot metal typesetting, “next page blank” provided considerable savings over “this page intentionally left blank,” but this may be a non-issue with electronic publishing.
A move to structured markup offers an excellent opportunity to ask: “Why do we do it this way anyway?” and “If there were no limitations, what would be the ideal?” The answers to these questions provide an excellent foundation for moving to a new formatting technology.
What are your current formatting requirements? What are the plans for the future? To what extent does formatting contribute to brand identity and competitive advantage? Are formatting changes generally incremental? Or are documents completely redesigned from time to time?
What languages and alphabets must be supported? What output formats are required?
Exactly what formatting does each vendor support today? What are their future plans? What conversions are required? What other technologies, languages, compilers, plug–ins, or products, are involved?
Some formatting is relatively easy to support in a batch process. Other formatting is extremely difficult if not impossible without manual intervention.
Lights-out formatting is less expensive than interactive formatting. The up-front price for stylesheet development may seem a bit steep at first, but a batch stylesheet soon pays for itself because the more you use it, the less it costs. With interactive formatting, the more you use it, the more it costs.
Is lights-out formatting feasible for your present and future formatting requirements? How much hand crafting is needed? What human intelligence is needed to achieve the desired formatting, and when in the publishing process is it needed? Is there any flexibility in the requirements?
What do vendors plan to support in the future? Will vendors work with you to find a way to support your current and future requirements?
Performance needs vary from one organization to another. What is required for your applications? Are your documents short or long? Is major transformation needed?
What processes are required for authors, editors, and subject matter experts to see a preview or print? How long does it take? Be sure to evaluate the time for this attended process which is repeated countless times during a document's life cycle.
What information is available from vendors about performance related to their support for stylesheet languages and your specific formatting requirements?
Ideally, stylesheets should be developed by people who know about text, and that usually does not mean IT programmers. In his AUGI 2005 presentation “Getting Native XML on the Authors' Desktops,” X.Systems' Barry Schaeffer pointed out that IT folks need to be reminded that there's a lot about text that they don't know (obviously, there are exception cases, the late Paul Klock of Arbortext being an exceptional example).
Whether publishing personnel can handle stylesheet development, however, depends a lot on the development tool, regardless of the language. If a tool requires users to be programmers, most publishing folks won't be successful no matter how much training they receive, and the task will fall to IT — which solves one problem by creating a new one: the need for IT programmers to acquire the necessary domain knowledge.
Note that while it may seem more “efficient” to have one applications developer handle all languages, publishing professionals know all too well that it is impossible to effectively proofread one's own work. Experience proves that a team approach to application development results in a better quality application and smoother deployment.
Who in your organization is best suited to developing stylesheets? Are they programmers? What tools are available at what price? Keep in mind that “graphical user interface” means different things to different people.
Only rigid enforcement of single sourcing will guarantee information integrity. Some SGML/XML solutions produce formatted versions that can be changed without changing the source. The danger of this approach was learned in the days before electronic print masters when one could quickly paste a correction on camera-ready copy while pledging to update the source file later. In real life, the source is not always updated which inevitably leads to database corruption — it's only a matter of time.
What is the cost to your organization of errors and inconsistencies in published information?
Arbortext Editor with ACL and FOSI is a powerful combination designed to work together to support complex, interactive applications for authoring, editing, and publishing processes. For example, my original proof-of-concept application for change processing required only FOSI and ACL.
Where does Arbortext fit into the big picture for your organization? What other processes, languages, and technologies are involved?
Who in your organization will use Arbortext Editor? What will they need to succeed with Arbortext Editor and structured markup?