Rendering Engine Review—Final Report

A PDF version of this document is also available (PDF version, 309KB).

Timothy Arnold-Moore, Legislation Management Consultant
Ozhan Hassan, Senior Programmer
InQuirion Pty Ltd

InQuirion Pty Ltd, 2004. All rights reserved.

Table of Contents

1. Background
1.1 Purpose
1.2 Importance of rendering solution
1.3 The existing solution
1.4 Outstanding issues with the rendering engine
1.5 Example document set

2. Process
2.1 Creation of the base document and shells
2.2 Example generation tool
2.3 Rendering solution assessment

3. Alternatives
3.1 ArborText E3 (ADG)
3.2 XyVision XPP (XyVision or ADG)
3.3 Advent Publishing 3B2 (Allette Systems)
3.4 Elkera XML Print (Elkera)

4. Assessing against rendering issues
4.1 Performance
4.2 Line numbering
4.3 Change tracking
4.4 Running headers
4.5 Dual column and single column on the same page
4.6 Future fit
4.6.1 Standards and future proofing
4.6.2 Maintainability of stylesheets
4.6.3 Production of annual volumes and reprints
4.6.4 Other output formats
4.6.5 First on page issues
4.7 Economics

5. Conclusions

6. Declaration of interest

1. Background

1.1 Purpose

InQuirion has undertaken a technical review of the Public Access to Legislation (PAL) project for the New Zealand Parliamentary Counsel Office (PCO) to enable PCO to reassure the New Zealand Government, as sponsors of the PAL project, that the PAL system, when implemented, will be operationally stable, maintainable, and capable of supporting future enhancement and development. The Final Report of the Technical Review ("the Technical Review") made a number of recommendations with respect to the rendering solution—which takes XML documents and produces paper or PDF renditions of the documents.

As a follow up to that review, the PCO requested that InQuirion further investigate alternatives to the existing rendering solution, specifically ArborText's E3, XyVision's XPP, and Advent Publishing's 3B2 ("the Rendering Engine Review"). During the course of the Rendering Engine Review, InQuirion were also approached by Elkera, who developed the South Australian drafting system, which includes a rendering engine component. This report captures the results of the Rendering Engine Review evaluating each of the 4 potential replacements of the existing ArborText PrintComposer solution.

1.2 Importance of rendering solution

As noted in the report, the longevity and importance of legislative documents combined with the time pressures placed on the agencies supported by the PAL system are such that they are particularly attentive to the quality and timeliness of paper output.

'The ability to produce accurate, high quality, timely print renditions of legislation—in draft, final, and consolidated form—is crucial to the success of the PAL system.' s. 6.2.2

When PAL goes live, the final responsibility for producing paper output will fall on the Pre-Publication Unit. As the report notes:

'The Pre-Publication Unit will be taking on the publication role formerly undertaken by Legislation Direct. They will bear the primary responsibility for ensuring that the correct stylesheets are applied to the correct documents, that the output of the print process produces high-quality page presentation, and that the documents are made available in a timely fashion, both in print and electronic form, once the content has been created. They will also be responsible for managing the more unusual inclusions in legislation such as graphics, treaties and deeds, and complex tables. A well-crafted print and electronic rendering solution as part of the PAL system should eliminate much of the stress of this typesetting role and allow the PPU to concentrate on the presentation of the more unusual elements.' s. 3.4.4

Legislative documents are amongst the most important in the land. Most of them will still be in use many years from now. The paper artefacts are still the lasting and normative expression of the will of Parliament and the Executive. Future users of legislation will judge the current work not only by the quality of the text drafted, but also by the quality of the presentation of the legislation.

The expectation by the legal community and Parliament of the quality of the output should reflect the investment in the PAL project and the resources dedicated to prepublication, and the importance of the documents. While many compromises are possible, the output should not exhibit obvious errors—encouraging the perception that it was not checked sufficiently, should demonstrate high production values—encouraging the perception that the PAL system is delivering value for money and that legislation is being treated appropriately by the PPU, and should not compromise the longevity of the documents—either by embedding system-specific mark-up to ensure that it looks right now but may not in another system or by sacrificing timeliness of delivery now for quality of appearance that will be visible for many years to come.

Beyond these general constraints, certain aspects of formatting can affect how the legislation is interpreted or impact the legislative process. The indentation of "sandwich" text determines with which structural elements it is associated. This can affect interpretation—whether a qualification of a list of items applies to all items in the section or just the items immediately preceding the "sandwich" text. Line numbering in Bills is used as the basis for describing amendments during the committee process. Incorrect or inadequate line numbering may cause confusion as members and their staff consider proposed amendments to Bills during the committee stage (either select committee or committee of the whole). Any such problems will be very public and could be used as a political tool.

1.3 The existing solution

At the time of the technical review, the PPU did not have confidence in the rendering subsystem as delivered to the PCO as part of the PAL solution. This directly affects PCO's ability to deliver paper output from the PAL system to the various stakeholders. While considerable co-operation has been received from both Absolute Data Group (the sub-contractors) and ArborText (the suppliers of the rendering technology) in addressing the concerns in the Technical Review, regaining the confidence of all PCO staff in an ArborText-based solution delivered by ADG will be a long battle.

The PAL system, as currently delivered to the PCO by Unisys, uses the ArborText Epic PrintPreview capability to allow authors to view the documents in their final print form interactively as they are editing and the Epic PrintComposer in combination with Adobe Distiller to produce final camera-ready copy (in PDF form which can be reliably printed to reproduce an exact page). The production process is managed by a Java application called from the content management system to ensure that print requests do not interfere with each other and that the appropriate files are generated when requested. This Java process generates and calls a batch file that uses PrintComposer to turn the XML into PostScript. A separate batch file invokes Adobe Distiller to turn the PostScript document into a Portable Document Format or PDF document.

An XML rendering engine typically takes one or more input XML documents and a stylesheet and produces a camera-ready output, often as a PDF encoded document. The ArborText products, both the existing PrintPreview and PrintComposer and the proposed E3, support two languages for creating stylesheets—Formatting Output Specification Instances (FOSIs) and XML Stylesheet Language Transforms (XSLT) used with XML Stylesheet Language-Formatting Objects (XSL-FO). FOSIs were selected because of the limitations of XSL-FO, particularly with respect to headers and footers and mixing two-column and single column layout on the same page. Although the FOSI standard is more powerful than XSLT/XSL-FO, the technical report noted its limitations:

'This standard is an old Defence standard, ¹ designed for SGML that allows a developer to describe the presentation of each element and attribute. Like the W3C's CSS standard, FOSIs have limited capability to present content occurring once in the document in multiple places in the document (e.g. the title on the title page and in the running header) or to reorder the content for presentation. Although this is an open standard, there are few vendors still supporting it (primarily ArborText and Datalogics). Most have migrated to the W3C standards CSS² or XSL-FO. ³'

A significant number of the outstanding defects with the PAL system relate to the formatting of the legislation into print-ready form. This investigation reveals that the defects arise from both limitations in the rendering engine and limitations of the configuration by Absolute Data Group (ADG). Limitations in the configuration can be largely attributed to a failure to sufficiently elicit the complete rendering requirements in a timely and effective manner. It is not clear who is at fault for this failure but a more formal requirements documenting phase and more careful regression testing regime to ensure that requirements already satisfied are not undone will go a long way to address these defects. InQuirion notes that ADG were extremely co-operative during the Rendering Engine Evaluation process and made significant effort to address issues raised in the technical report and in the course of the review. In particular, ADG substantially addressed the performance issues raised in the technical review and made substantial in-roads with respect to maintainability.

It should be noted that the existing solution has some licensing issues. It currently uses ArborText PrintComposer in "lights-out" mode. Communication received from ArborText during the course of the project suggests that the licences do not allow the product to be used in this manner. They suggest the appropriate ArborText solution is the server product, E3. Time pressures in the original roleout lead to a negotiated solution with ArborText allowing the project to proceed with PrintComposer. Likewise, the current solution uses the personal version of Adobe Acrobat (which includes Distiller). Licensing of this product does not allow it to be used as a server servicing requests from multiple users. The server version of Distiller would have to be purchased before putting the current architecture into production.

This review is motivated by the need to find a more sustainable, long-term solution.

1.4 Outstanding issues with the rendering engine

Sections 1.2.1, 6.2.2 and 7.2 of the Technical Review set out the issues of concern with respect to the rendering solution. These are summarized as follows:

'A number of different stakeholders have considerable reservations about the current print rendering solution. InQuirion shares their concern.

'These issues focus around performance, functionality, and future fit, and the economics of continued deployment.' s. 6.2.2

This report has focussed on the issues of most concern preventing immediate deployment of the existing solution:

• Performance—to produce paper renditions of large documents in a timely fashion,
• Functionality—to produce correct output of high quality reliably. In particular the current solution has exhibited problems with:
  • Line numbering, and
  • Change tracking—the complex combinations of bold and normal face fonts with heavy and light, double and single, strike-through and underline required for two levels of change tracking showing majority and unanimous changes.
• Alternative solutions were assessed against these weaknesses in the existing system and also against some of the trickier aspects that the existing solution copes with including:
  • Running header—ensuring that the divider line between the header and the body stays at the same point despite changes in the number of lines required by the header, and
  • Use of a two-column table of contents possibly on the same page as a single column body or preamble.

• Future fit—the complexity of the rule set and the feasibility that PCO could manage changing the rule set or would require outside consultants for ongoing management.
• Economics—the cost of fixing the existing solution versus redevelopment on an alternative platform.

1.5 Example document set

The Technical Review also recommended:

'that the User Acceptance Team prepare a set of documents in XML and PDF that can be provided to Unisys and ArborText for confirmation of their project plans and against which to validate candidate releases. This set of documents together with the layout specifications should be provided to selected vendors of alternative rendering engines to ensure that a fallback position is preserved and to explore the cost-effectiveness of alternative solutions.'

The PCO UAT prepared an example document that attempts to explore as many possible elements as practical in a single document—the base document. InQuirion was commissioned to create a tool to take this mammoth document and a number of smaller shell documents representing the various stages of Bills, Acts, Regulations, and SOP's and insert all or part of the body and schedules from the base document stripping out tags not relevant in those types of document. For particular stages, the tool was also to apply change tracking markup to produce examples of the likely combinations of markup that would appear in the normal legislative processes. While this tool, at the time of the review, generated some change markup combinations permitted by the DTDs that were not likely to occur in practice and was not able to produce some markup combinations likely to occur in practice but not permitted by the DTDs, the examples generated were sufficient for all vendors to demonstrate the capabilities and limitations of their products to render this type of markup.

2. Process

There were three main phases in the Rendering Engine Review:

• the creation of the base example document and other shell documents by PCO UAT;
• the creation of the example generation tool by InQuirion;
• the provision of example documents to the vendors and the assessment of the rendering engines' capabilities and performance by InQuirion in consultation with the vendors.

2.1 Creation of the base document and shells

The PCO UAT developed a single mammoth document containing a mix of all different provision types possible in a body with as many included elements in as many different contexts as practicable in a single document. This document contained over 10Mb of XML content (not including images), 200,000 XML elements, and renders to over 2500 pages using the current rendering solution. A document of this size and complexity is extreme and designed to test the limits of the rendering solution. A rendering solution capable of rendering this document (subject to the completeness of its coverage) should be able to manage Bills, Acts and Regulations produced in normal processes. ⁴ In practice, most Bills and Regulations are smaller than 100 pages. However, a Bill prepared last year was over 1500 pages and such large documents are likely to be politically sensitive and create timeline pressures on the agencies delivering them to the various legislative stages and the public so it is important to cater for the extreme.

These inputs as defined in the Print Rendering extension to the original technical review require:

• 'an input draft XML document conforming to the NZ PCO DTDs as provided to InQuirion, likely to be more than 2000 pages and to contain examples of every single element possible in the Body or Schedules in as many different contexts as is practicable (excluding change markup);
• 'a set of XML fragments that represent typical front and tail fragments for each of the document types below including an explanatory note in the Bar 1 and a commentary in the Bar 2, and the various metadata necessary for a Bill, Act, draft regulation, or published regulation (note some indication of which metadata fields are normally completed at each stage will be necessary but, where the metadata is simply added in each subsequent stage, duplicate fragments will not be required); and
• 'one or more input SOP and slip amendment documents'

Coverage analysis of the example document shows that there are still a large number of contexts allowed by the DTD but not covered by the example. It is possible that these contexts will not appear in reality and are simply a consequence of an overly permissive DTD but InQuirion suggests that some gap analysis be performed before committing to these particular examples as the complete specification of the rendering process.

2.2 Example generation tool

The tool as developed by InQuirion takes an XML configuration file that specifies the base document, a directory in which to find the shells, a directory in which to put the output documents, and a list of shells and instructions on how to process them in order to produce the output. The configuration file with provided base document and shells produces:

• a draft Bill;
• a Bar 1 introduction Bill (including an explanatory note);
• a revision tracked draft Bill for consideration of a select committee with change markup applied within and to as many element combinations as is practicable (the change mark-up is generated by the tool);
• Bar 2, and Bar 3 with change markup applied to elements randomly selected from those eligible to have change tracking markup applied;
• Assent copy;
• the Act as it would be printed in loose leaf form;
• for each of the various types of regulation:
  • a draft regulation, and
  • the copy for the Governor-General's signature;
  • the regulation as it would be printed in loose leaf form; and
• an SOP with amendments showing each of the appropriate elements.

2.3 Rendering solution assessment

Initially, the base document was provided to each of the vendors together with a PDF generated from the existing rendering solution. Later in the process, the other document types were also provided to the vendors to illustrate the remaining issues.

Vendors were asked to demonstrate the capabilities of their product with respect to each of the issues identified above:

• Line numbering,
• Two-column table of contents with single-column body,
• Ability to position the header for various length document titles, and
• Change tracking and how stylesheets developed for the non-change tracked base document could be modified to support the PAL change tracking requirements.

The vendors were also asked to give indicative estimates based on the documents provided and suggest how they might go about configuring their products to support the PAL project and how ongoing maintenance might be managed if their solution were selected.

The vendors were selected in consultation with Unisys and PCO. In particular Unisys proposed ArborText's E3 product as an alternative to the older PrintComposer, InQuirion suggested that Advent Publishing's 3B2 product also be included because of changes in the distribution arrangements which made it a viable alternative, and XyVision's XPP which was considered in the original evaluation but rejected as overkill for the PAL requirements. Elkera's XML legislation rendering solution was later added to the list as a result of communication from Elkera to InQuirion with approval of the PCO. InQuirion was previously unaware that Elkera's solution provided such a comprehensive rendering solution and had assumed that South Australia OPC was using an XSL-FO solution.

3. Alternatives

3.1 ArborText E3 (ADG)

ArborText is a well-respected US company with an excellent reputation in the SGML and XML communities. They have participated in standards development over many years, including participating in the development of XML itself. Their flagship product, the Epic Editor, is widely regarded as the most fully-featured XML (and SGML) editing tool available. Absolute Data Group is the sole distributor of ArborText products in Australasia.

The print rendering solutions are more recent additions to ArborText's product line. While mature products in the Defence technical manual arena (ArborText's primary market), they are not widely considered to be high-end publishing solutions. InQuirion is unaware of a successful deployment of an ArborText rendering solution in a legislative drafting and publishing environment. While the PrintComposer and PrintPreview tools are interactive products, designed for a particular user to select an input document and produce a single output document (as a PostScript file), the E3 server is designed to be a transformation server. It is typically invoked on a central server machine from client machines. The recommended approach for this project is to invoke the server using a web service interface from the CMS. An interactive user interface invoking the server via this web service model was demonstrated by ADG to InQuirion.

Unlike the PrintComposer solution delivered as part of the existing PAL system which can only render one document at a time, E3 is a multi-threaded server accepting multiple rendering requests and allowing them to be processed in parallel. It achieves this by initiating two separate processes per request. The first appears to be using a modified TeX engine to render a single XML document into a PostScript rendition. The second appears to manage Adobe's distiller to render the PostScript document as a PDF. Version 5 of E3 has its own PDF production capability but this was not demonstrated to InQuirion. ADG were able to demonstrate to InQuirion that multiple requests were processed faster than separate requests processed serially even on a single CPU machine with a single disk spindle. A multi-CPU machine and parallel disk arrays should further improve parallel throughput of requests. This parallelization would render much of the existing Java infrastructure in the CMS unnecessary as E3 itself would manage the entire rendering process. Providing Version 5 of E3 is deployed, licences to Adobe Distiller will not be required.

The change required to the existing application would be the replacement of calls to one of the custom Java modules with calls directly to E3. This simplifies the architecture and eliminates some custom code but means that the changes necessary to integrate E3 into the CMS processes are not dissimilar to the changes necessary to integrate the alternative rendering solutions.

With the exception of the parallelization, the actual rendering engine appears to be very similar to that in Epic Print Preview and Epic PrintComposer. It supports both FOSIs and XSL-FO as stylesheet languages. Similar bugs were found in renditions of the example documents in both the existing solution and the E3 solution using the same or similar FOSIs. These problems are most likely FOSI configuration limitations although the only way to be absolutely certain of this is to demonstrate a working solution. Because of the similarities with the existing solutions, it would be appropriate to continue with the existing PrintPreview solution for interactive previewing if E3 is the selected solution. This will be most effective where the versions of E3 and Epic Editor match but they need not be synchronized. Alternatively, the authoring environment could be modified to invoke the same web service as the CMS to produce a PDF that could be viewed by the user using Adobe Acrobat Reader on the desktop (already part of the standard operating environment in PCO, OC, and IRD).

Although the version demonstrated to InQuirion was version 4, ADG claim that version 5 of E3 also has better support for strike-through and underline. This may obviate the need to use special fonts for the change markup described above.

This approach is a "black-box" rendering solution. The only opportunity for modifying the output of the rendering engine is to modify the input document (either by changing the markup or embedding proprietary processing instructions using the "touchup" capability) ⁵ or modifying the stylesheets. Use of the "touchup" capability is undesirable because it introduces into the markup proprietary dependencies and is not supported for web output. The "touchup" facility cannot override autotext such as running headers. However, "touchup" can be used to overcome isolated limitations in vertical and horizontal spacing, page and line breaks and similar formatting problems. Clicking in PrintPreview does not take the user to the corresponding markup in the source document making it more difficult to modify the non-proprietary content markup interactively than it would be for some other solutions.

An obvious advantage of E3 over the other alternatives is that the current FOSIs could be used. However, there are a number of difficulties with the current FOSIs that suggest that a considerable re-write would be preferable anyway. Regardless of the rendering solution selected, continuing with the current authoring solution will necessitate maintenance of FOSIs for displaying the documents in the editing tool. A few rules within the existing FOSIs contain different rules for print rendering and screen views so there is already a small additional burden. The additional burden of maintaining screen views with other rendering solutions would be greater.

The FOSI standard is an SGML/XML encoding of the rules for each context. ArborText provides a user interface for creating initial stylesheets (Styler), which outputs these SGML stylesheets. This tool will also translate FOSIs it understands into XSLT/XSL-FO stylesheets to the extent possible. Any additions to FOSIs beyond the capability of Styler cannot be readily modified by Styler. Nor can they be migrated out to XSLT/XSL-FO. The FOSIs delivered as part of the PAL solution provided a rule for each and every context supported. Little use was made of inheritance and significant redundancy was found in the unnecessarily large number of rules.

Considerable effort has been expended by ADG during the course of this review to address the limitations of the original FOSIs. In particular, ADG have demonstrated that E3, PrintPreview, and PrintComposer are all capable of using more inheritance than was exhibited. Some small changes to markup relating to change tracking whole elements could further reduce redundancy. This is also true of the alternative rendering solutions (except 3B2 which can achieve the same effect with the current markup).

Neither E3 nor PrintComposer was configured to provide vertical justification of pages.

3.2 XyVision XPP (XyVision or ADG)

XyVision/XyEnterprise is a US company providing publishing hardware and software. They have delivered SGML and XML rendering solutions to many large scale publishers including New Zealand legal publishers, Brookers and Butterworths, as well as other traditional users of SGML and XML including technical documentation producers and pharmaceutical companies. Originally SGML and XML were supported by mapping to a proprietary markup language, but more recent versions support XML and SGML directly. XyVision have a small local office with a single technical resource based in Sydney. Additional resources are available around the world direct from XyVision and from partners. ADG has worked with XyEnterprise to integrate with some of their products and are familiar with the capabilities and limitations of the product.

Although XyVision provide a content management system and a number of other applications to manage the process of constructing stylesheets or producing documents, the print rendering engine is their flagship product. XPP supports loose-leaf publication, scientific articles (including complex chemical and mathematical formula), and magazine publishing, all from XML source documents. The rendering engine can be invoked on a server from the command line (similar to the current solution using PrintComposer), by a number of "watched directories" where users place documents in the directories and the server periodically checks the directories and performs pre-programmed series of actions on the files (typically to produce a PostScript or PDF output), or as a web service (like that proposed for E3). To use XPP in this way to generate PDF would require a server licence to Adobe Distiller.

XyVision also provide additional tools for interactively managing the rendering process including XyView which allows experts such as the PPU to interact and control the rendering and modify stylesheets. Any stylesheet-based rendering solution allows modification to the stylesheets to control the rendering. The difference with the XPP solution is the degree to which this process can be interactive using XyView. It is not proposed that XyView be provided to drafters, only to experts in typography such as those in PPU or IT support. Any changes to stylesheets would be isolated to a particular document and only propagated to the entire system after appropriate testing on a broader selection of documents.

The simplest integration with the existing PAL system would be to replace the command line calls to PrintComposer with similar command line calls to XPP. This would take care of CMS integration.

Using the existing PrintPreview solution is only appropriate with an ArborText rendering solution. It would be inappropriate to use ArborText PrintPreview with a non-ArborText rendering solution as the preview would be misleading. Rather it is appropriate to configure Epic Editor to call the actual rendering engine (in this case XPP) to generate a PDF which would then be viewed on the client machine using Adobe Acrobat Reader (part of the standard operating environment in PCO, OC, and IRD).

This approach is also a "black-box" rendering solution with the only opportunity for modifying the output of the rendering engine being by embedding processing instructions in the input document or modifying the stylesheets. However, the use of XyView allows individual pages to be re-rendered. This means that any "tweaking" of the document can be done interactively without re-rendering the whole document giving a sub-second turn around when making minor modifications to a very large input document. Because cross references in legislation are based on structural components and not page numbers, there is significantly less risk in a localized rendering (of say 5 pages within a 1500 page document) introducing errors in other pages. Providing that a user in this mode starts at the beginning of a document and renders a few pages forward at a time rather than the whole document every time a change is made, interactive layout would be considerably less time consuming. Suppose a typographer is "tweaking" a 1500 page document and a minor tweak is required on average every 5^th page. That means about 300 tweaks in a single document. If the tweak is about line or page breaks, then the whole document needs to be re-rendered for each tweak. If it takes 1 minute for a print preview (not the 5 minutes to produce a PDF), that means a minimum of 300 minutes or 5 hours of rendering not counting the time it takes to actually enter the tweaks. If each tweak can be re-rendered in less than 5 seconds, the total rendering time is more like 25 minutes.

XyView supports a user clicking on the rendered page to navigate directly to the corresponding markup in the source document and allows identification of the rules fired in the stylesheet. This capability could be configured into Epic Editor only with considerable developer effort but, since only typographers in PPU would make use of XyView for this type of document cleanup, using XyView to do these minor markup changes would be quite practical.

XPP supports its own proprietary stylesheet language. The primary means of editing stylesheets is using XyView with drop down lists and text boxes for inputting the various details per context. Using XyView, a user can navigate directly from the rendered document to the rule fired to produce that part of the page. Any complex logic must be written in an arcane and non-intuitive macro language.

As with all of the rendering alternatives, this would require a separate stylesheet for print rendering to that used for the screen view in Epic Editor. Unlike the E3 solution, the two stylesheet languages would be different so rules could not be shared between them.

XPP was configured to automatically vertically justify pages. Because changetrack markup is relative to the text to which it belongs, change tracking behaves correctly during vertical justification.

3.3 Advent Publishing 3B2 (Allette Systems)

Advent Publishing is an English company providing rendering software. They have delivered SGML and XML rendering solutions to Texas and Canadian legislatures as well as large publishers, technical documentation producers and pharmaceutical companies, with direct support for XML and SGML. Although they do not actively participate in standards development, they have a strong reputation for supporting international standards particularly in their support for Unicode and multiple languages. Allette Systems, based in Sydney, have a distribution agreement for 3B2 in Australasia with one primary resource available for 3B2 customization. Advent has offices in England, Europe and the US with a large number of additional 3B2 consultants available. Allette were involved in the legislation authoring and delivery solution to the Singapore drafting office.

Like XyVision's XPP, Advent's 3B2 is their flagship product. 3B2 supports looseleaf publication, scientific articles (including complex chemical and mathematical formula), and magazine publishing, all from XML source documents. The rendering engine can be invoked on a server from the command line (similar to the current solution using PrintComposer), by a number of "watched directories" where users place documents in the directories and the server periodically checks the directories and performs pre-programmed series of actions on the files (typically to produce a PostScript or PDF output), or as a web service (like that proposed for E3).

The simplest integration with the existing PAL system would be to replace the command line calls to PrintComposer with similar command line calls to 3B2 although a simplified Java infrastructure could make requests via a web service similar to that proposed for integrating E3. Since 3B2 generates its own PDF, it does not require Adobe Distiller. As with XPP, integration with the authoring solution for interactive previewing would require a call from Epic Editor to the server to generate a PDF which would then be viewed on the client machine using Adobe Acrobat Reader (part of the standard operating environment in PCO, OC, and IRD).

This approach is also a "black-box" rendering solution. Again, the output of the rendering engine can be modified only by modifying the input document or the stylesheet. Advent also provides an interactive preview tool similar to XyView to support interactive "tweaking" of the document. Like XyView, this tool allows clicking on the rendered page to navigate directly to the corresponding markup in the source document and allows identification of the rules fired in the stylesheet. Unlike XyView, the whole document is then re-rendered.

Like XPP, 3B2 supports its own proprietary stylesheet language. Modifying stylesheets involves direct editing although Allette are developing an XML stylesheet language not unlike that used by Elkera XML Print. This would not be available to meet PCO deadlines. The language can also call out to other scripting languages such as Perl for complex text manipulation.

As with all of the rendering alternatives, this would require a separate stylesheet for print rendering to that used for the screen view in Epic Editor. Unlike the E3 solution, the two stylesheet languages would be different so rules could not be shared between them.

3B2 was demonstrated with pages vertically justified automatically. Because change-track markup is relative to the text to which it belongs, change tracking behaves correctly during vertical justification.

3.4 Elkera XML Print (Elkera)

Elkera is a relatively new Australian company based in Sydney highly focussed on the XML legal market, particularly support for drafting offices. Elkera's main customers include the drafting offices in NSW, ACT, and South Australia. Elkera provide boutique XML and SGML consulting services but they have also developed a generic XML publishing system aimed primarily at drafting offices. Elkera, and the principle technicians—Peter Meyer and Andrew Squires are well known supporters of standards in the SGML and XML community in Australia. They have a team of 8 developers based in Sydney further developing the Elkera product offering and providing configuration services.

Elkera's authoring and publishing system, XML-2-Go, includes an easily configured editing environment based on Corel's XMetaL editor, a number of tools to assist managing legislation including cross-reference and numbering tools, and a rendering engine, XML Print. The rendering engine applies a proprietary XML stylesheet and XML configuration files to produce an RTF document. This document is then managed by the system to invoke Microsoft Word (or another RTF engine) to produce paper copy or, in combination with Adobe Acrobat, PDF output.

As with all of the rendering alternatives, this would require a separate stylesheet for print rendering to that used for the screen view in Epic Editor (unless the Elkera editing solution was also adopted). Unlike the E3 solution, the two stylesheet languages would be different so rules could not be shared between them.

The XML-2-Go system is a library of Java code invoked from XMetaL using various scripting languages also available in Epic Editor. Integration with the CMS would be provided by calling the appropriate Java libraries from the Java transforms instead of invoking the current batch files much like invoking the E3 web services.

For print previewing, Epic Editor would need to be configured to call this Java library so that authors could be presented with either a locked RTF document in Word or WordPerfect or a PDF document produced directly from WordPerfect or by using Word and Adobe Acrobat. This could be done locally rather than relying on a network connection to a server. The current desktop deployment environment used within PCO would ensure that all users are using the same stylesheets and that stylesheet changes are propagated in a controlled manner after appropriate system and regression testing (as with the current PrintPreview approach). This also applies to version control of the underlying word processor used to actually render the document. This ensures that a distributed rendering approach would achieve the same uniformity of result as the centralized server approach of the other rendering solutions. Note that this preview capability is already integrated into the current Elkera editing solution.

There are two clear advantage of this approach. The first advantage is the experience of the principals of Elkera with legislative drafting and delivery in Australasia. None of the other vendors is proposing to use personnel with direct experience of legislative drafting environments although Advent has people who worked on the Canadian project available based in the UK and Allette have people experienced with a legislative drafting environment in Singapore. Experience with legal publishers was available for all vendors but there are significant differences between legislative drafting offices and commercial legal publishers.

The second advantage is the ability to intervene in the "black-box" process. While South Australia treat Elkera XML Print, Word and Acrobat as a single black-box without intervening, it is possible to open the RTF output in Word or WordPerfect and modify those documents directly if the rendering engine does not produce the desired output. While this is obviously not desirable in general usage, it means that, in a time-pressured environment, appropriately authorized staff could produce the correct document on the spot when stylesheet expertise or rendering engine fixes are unavailable. This would allow changes to be made in an environment where modifications to a stylesheet or underlying application could not be performed in time. Obviously, this is not a permanent solution. Once the immediate urgency of getting a particular document out of the door had been addressed, the stylesheets or application would then need to be modified to ensure that subsequent rendered versions of that document could be produced without intervention.

The simplest way to ensure that this path is capable of producing acceptable output is to prepare a Word or WordPerfect document that meets the current formatting requirements preferably using only paragraph and character styles rather than relying on direct formatting. As part of the rendering engine review, PCO prepared Word and WordPerfect documents that illustrated the capabilities and limitations of this path. Neither Word nor WordPerfect as rendering engines provides a good automatic vertical justification solution. Other RTF rendering engines may but these were the only candidates tested. It would be possible to extend the Elkera solution using a VBA macro (for either Word or WordPerfect) to overcome the vertical justification limitations but this would add additional processing (and hence time) to the rendering process.

4. Assessing against rendering issues

4.1 Performance

While performance of the delivered rendering engine solution was definitely an issue, this turned out to be a minor configuration problem to do with generated text which, when rectified, resulted in remarkable improvement in performance, from many hours for a few hundred pages to a few minutes.

For a number of reasons, it is difficult to directly compare the performance of any of the solutions. None of them was so much faster or slower that performance alone would determine one solution over the others. While PrintComposer and E3 were applying a full stylesheet, XPP and 3B2 were demonstrated applying only a partial stylesheet to the provided document, and 3B2 and Elkera were demonstrated using similar stylesheets applied to XML legislation from other jurisdictions encoded in quite different DTDs but reflecting similar structures. Since only Advent provided evaluation licences to InQuirion, it was also not possible to compare each product on an identical machine configuration. For Elkera and XPP, Acrobat Distiller dominated the rendering time. It is a little more difficult to identify the Acrobat component of an E3 render but, given the similar complexity of the PDFs, the PDF production phase is likely to be of similar magnitude. Note that none of the solutions were providing PDFs with outline and cross-reference support. Adding either or both of these would most likely slow down the rendering by at least a minute or two on large documents.

Draft documents are rarely more than a few hundred pages so any of these solutions would be acceptable for production use in PCO. Note though that production of compilations (particularly compilations of the frequently amended income tax legislation) will require production of documents over 1000 pages at least a few times a year. Interactive "tweaking" of such large documents could become quite tedious but compilations are not under such time pressures as Bills before the House.

While ADG demonstrated on older hardware to InQuirion taking of the order of 30 minutes to render the 2700 page test bill, PCO have validated considerably faster performance on PCO's server hardware rendering in less than 5 minutes to PDF and less than a minute to print preview.

XPP demonstrated the fastest turnaround solution with the 2700 page test bill taking about 3 minutes on a 2 GHz laptop to turn PostScript into PDF and the XPP rendering engine taking less than 2 minutes to render the pages to PostScript—a total of 5 minutes on reasonably modest hardware. XPP with XyView also allows the individual re-rendering of separate pages in sub-second time when "tweaking" output.

Elkera's XML Print took a similar time to render a 700 page annual volume but this task was reading in 70 separate XML documents plus generating a separate index document so the tasks are not directly comparable. Total rendering time for a typical large Bill (around 200 pages) was under 3 minutes on similar hardware. While this is a little slower than the alternatives, it is also producing an RTF rendition of the document. For print previewing (especially of particularly large documents), the RTF could be viewed in Word or WordPerfect rather than producing PDF.

3B2 took less than 3 minutes to render the 2700 page document to PDF but this was with only a few rules firing. Rendering a similar sized bi-lingual document with two separate English and French input XML documents aligning each structural element took just under 10 minutes. These rendering requirements are considerably more complex than in New Zealand legislation (this was rendering the final form of Canadian legislation). One would expect rendering New Zealand legislation to be somewhere between these extremes probably closer to 3 minutes than 10.

To the extent that any of these results are directly comparable, it appears that all of these solutions are within the same ball park for producing a whole document and all provide acceptable performance for individual Bills. For interactive tweaking, XPP has a considerable advantage over the others.

4.2 Line numbering

Accurate and reliable line numbering is crucial to the committee amendment process. During the initial stages of the preparation of this report, ADG were unable to demonstrate a working line numbering solution using any ArborText rendering engine. Many of the problems exhibited in PrintComposer were shared by E3. ⁶ Late in the evaluation process, it was discovered that many of the problems reported to Unisys had not been communicated to ArborText. Once this was remedied, ArborText showed considerable progress on this issue. ArborText have provided assurances that they will fix any line numbering issues in their product. If these fixes can be demonstrated to PCO's satisfaction, this issue should not prevent E3 from being selected.

Both XyVision and Allette were able to demonstrate considerable power and flexibility in line numbering. Both warned that configuring line numbering for tables was more difficult, primarily because there is some ambiguity for arbitrary tables as to which column or columns should determine the line numbering. Both allowed ignoring particular elements for line numbering, resetting line numbering at the beginning of a page, ability to put the line numbers on either side of the page (the right side is preferred by PCO) and variable intervals between line numbers (5 is the standard for NZ).

Elkera demonstrated line numbering using Word as the RTF engine. This works reliably and consistently. Particular Word paragraphs can be ignored for line numbering and the interval can be set for each document section (5 is possible). It is possible to place the line numbering on the right hand side but only by installing multi-directional language support and setting the direction to left-to-right (the English text still renders in the right order but this may have other side effects). Word is not able to line number tables. Subsequent experiments with WordPerfect confirm that it too is able to ignore paragraphs, restart per page, and (unlike Microsoft Word) line number tables. We have yet to determine whether line numbers can be placed on the right side of the page using WordPerfect.

4.3 Change tracking

Perhaps the most unique requirement to New Zealand legislation and the most complicated for rendering engines to support is the requirement for multiple levels of change tracking. Unlike other jurisdictions, New Zealand provides as output from the select committees and the committee of the whole a document that typographically distinguishes changes made by that committee, and any previous committee. Changes made unanimously are distinguished from those made by a majority. This is means that a piece of text in a Bill can have applied to it most combinations of:

• bold, italic, or normal face to the text,
• double, single or no strikethrough in either normal or heavy weight, and
• double, single or no underline in either normal or heavy weight.

XPP provides by default 11 different types of rule through text which can independently be configured in terms of weight and position relative to the middle, top or bottom of the text. Any combination of these 11 types can be applied to the text independently of the weight of the underlying text. These combinations together are just enough to support PCO requirements. Additional rules could be introduced using the complex macro language of XPP.

3B2 can be easily configured to apply strikethrough or underline of various weights regardless of the underlying text but the default configuration specifies the same weight for the line in underline or strikethrough. More complex configuration is required to independently set these using text boxes which, like XPP float with the underlying text to ensure that vertical justification does not upset the markup.

Neither Word, WordPerfect, nor the ArborText products support independent setting of the weight of underline, strikethrough and the underlying text. To support this in the existing solution, fonts were created with the different combinations of underline and strikethrough required. These fonts were provided to Elkera allowing them to demonstrate the application of change tracking markup using Word as a rendering engine. A similar approach was used to test WordPerfect by PCO.

The only outstanding issues to do with change tracking and either PrintComposer or E3 are to do with the interaction between <strikeout> and other context rules. This occasionally results in unexpected indentation of struck out elements. During the course of the evaluation, a markup change was identified that would considerably simplify the rendering rules for all solutions except 3B2 (for which the current markup provides no problems). The change involves using attributes to indicate that a whole element is to be struckout (similar to those currently used to mark the insertion of an element) rather than the current practice of wrapping omitted elements with a start and end tag (<struckout>).

InQuirion believes that the advantages of simpler maintenance and stylesheet development are more compelling than the original validation requirements that lead to this particular markup artefact. Providing that the lifecycles are modified to ensure that documents will still be valid when the change tracking markup is stripped out, the creation of stylesheets for all rendering platform targets will be considerably simplified and many of the indentation problems and complexities of the stylesheets can be overcome.

4.4 Running headers

An issue that emerged during the configuration of the existing rendering solution is the requirement that the rule at the top of the page remain in the same place regardless of the size of the running header. The size of the running header varies depending on the length of the document title, and the presence of structural elements such as Parts and Subparts. The only way to support this using PrintComposer was to introduce an attribute to specify the number of lines taken by the running header. This is also true of the version of E3 demonstrated to InQuirion. While setting this attribute is not difficult, a change to the title, the format requirements or the adoption of a different rendering engine may render the initial selection incorrect. Remember that this data may last hundreds of years and the lifetime of an IT system is rarely longer than 10 years. ADG and ArborText claim that this limitation has been addressed in Version 5. This should be validated independently.

Both XPP and 3B2 were easily able to cope with this limitation without resorting to an attribute automatically setting the appropriate positions. Both vendors demonstrated switching between a fixed rule and varying the size upwards and fixed top and varying the position of the rule with simple switches in the stylesheets. This means that changes to the content of the title will not require changes to the attribute (it is not needed to correctly format) and changes to the format requirements or switching to a different rendering engine would not require changes to the content. Both engines were also able to resize the header if it became too large to fit avoiding headers getting too close to the top of the page. Both were also able to cope with headers referring to the first mentioned provision or the last mentioned provision on a page (depending on right or left side) and also could be configured to carry over the section number from a previous page.

Elkera were able to demonstrate substantial flexibility with running headers in Word but not the exact header requirements of the PCO. InQuirion's experience in rendering SGML legislation to Word in Tasmania suggests that the appropriate macros can be placed in template files that are included by the RTF if the native capabilities of Word are not sufficient to provide the necessary functionality. The VBA scripting language is available in either Word or WordPerfect. This may require an additional pass over the document increasing the total rendering time so some compromise between rendering performance and functionality may be necessary if this solution is selected. If concerns remain about this approach, an example Word or WordPerfect document could be prepared with a macro that produces a running header to PCO's exact requirements. We would then propose that Elkera extend their solution to include use of this macro or something similar.

4.5 Dual column and single column on the same page

All solutions were able to switch from dual column (for table of contents) to single column (for Preamble or body text) in the middle of the page. This was most complex to configure in 3B2 but involved relatively simple setting of a switch in the configuration for all of the other rendering solutions. Unlike ArborText PrintComposer or E3, XPP, 3B2, Word and WordPerfect were all able to produce a rule between the two columns of a table of contents. This was a limitation of the rendering engine and not just the FOSI configuration however, PCO had already agreed that it was acceptable to dispense with the rule.

4.6 Future fit

4.6.1 Standards and future proofing

With the exception of Elkera, all the alternatives support XSL-FO but all acknowledge the limitations of this standard and would not recommend it as a standard for stylesheets for New Zealand legislation. While development continues on this standard, it is verbose and requires specialist programming knowledge well beyond the average type-setter.

3B2 provides proprietary extensions to XSL-FO which would address these limitations but acknowledge performance disadvantages to this solution and recommend their proprietary stylesheet language.

Elkera, 3B2 and XPP all provide their own proprietary stylesheet languages and tools for developing and maintaining them.

Both ArborText platforms assume the use of the independent FOSI standard. This standard is old, limited in rendering capability, only supported by two serious vendors, and therefore does not provide the normal advantages associated with adopting a standard platform. Using FOSIs for stylesheets provides no less a lockin to the vendor than the proprietary standards of the other vendors. The "touchup" tool inserts proprietary processing instructions in the markup which would not be handled by any other vendor providing additional lock-in. Other tools could be configured to translate ArborText processing instructions into processing instructions for other rendering tools or stylesheets to apply the intent of the processing instructions (this was demonstrated in part by XyVision).

Stylesheets created using ArborText's Styler tool can be exported as either FOSI or XSLT/XSL-FO stylesheets. FOSIs that have additional complex styling inserted manually to the output of the Styler can be imported back in but the effect is lost when you export back out to either FOSI or XSLT/XSL-FO. Since the existing stylesheets have been extended considerably, additional work would always need to be done manually after any transformation. ArborText have provided no commitment to support arbitrary FOSI to XSLT/FO translation although it is likely that, when FO is sufficiently feature-rich, their customer base will demand a more complete migration strategy. The alternative would be to create a custom stylesheet to map a FOSI to an XSLT transform capable of producing matching XSL-FO or to do the translation manually.

The reality is that there is no standards-based solution with the required flexibility and capability to meet PCO's requirements and no immediate prospect of one being developed.

Elkera's compromise is perhaps the best—to provide an XML stylesheet language that is simple enough to be understood by non-programmers but powerful enough to support all of the features required to render complex legislation. If and when a widely adopted standard comes along that meets all of the rendering requirements, a transform could be written to take the proprietary XML and produce stylesheets in the new, open standard. This is similar to the position of FOSI to XSL-FO with ArborText products except that Elkera's stylesheet language is simpler, and more powerful so the translation would be easier. Allette are working on a similar stylesheet language (Pure) for the 3B2 product mapping the XML into the native stylesheet language. Unfortunately, the 3B2 solution won't be available in PCO's timeframe.

Elkera are also planing to introduce WordML as an additional output format. Microsoft's support for this standard, essentially an XML form of RTF, will ensure that it has some traction in the market.

4.6.2 Maintainability of stylesheets

Elkera XML Print, XPP, and 3B2 all support hierarchical inheritance in context rules. This means that rules for a particular element can inherit properties from their containing elements. A <struckout> element can infer strikethrough on any text whether in a <prov> element or a <label-para>. Neither of these would need to refer to its parent to get relative indentation, rather it could rely on inheriting additional levels of indentation, say because of an <amend> tag. This approach leads to predictable and manageable behaviour of elements and generally fewer context rules in a stylesheet. While FOSIs support inheritance, because of the lack of a thorough lay-out specification, ADG chose not to use inheritance in the stylesheets originally delivered to PCO.

During the course of the rendering review, ADG provided revised FOSIs to PCO which rely on inheritance to simplify the number of rules and improve the maintenance burden. However, these stylesheets reintroduced defects that were previously fixed and further undermined PCO's confidence in the current rendering solution (and by implication an E3 rendering solution). InQuirion believes that these issues have less to do with the capabilities of the rendering engine and more to do with indirect communication channels and inadequate project processes and are best addressed by preparing a formal layout specification and a formal regression testing regime for stylesheet changes. This would do much to restore confidence for PCO.

The PCO, and in particular PPU, were justifiably reluctant to go forward with a black-box solution, reliance on an outside contractor to fix stylesheets, and a demonstrated track record of introducing new defects with each new release. Unisys has indicated that it will work more proactively with ADG and PCO to achieve empowerment of PCO with a FOSI-based solution and a more appropriate regression testing regime.

Elkera and XyVision demonstrated a much more proactive approach to user empowerment with respect to stylesheet maintenance. Elkera's goal in producing their XML Print solution was to empower the South Australian PCO, who have no internal IT support, to maintain the stylesheets for rendering legislation themselves. They have certainly gone a lot further down this path than any of the alternatives. With an XMetaL configuration to provide a neat solution for editing stylesheets and a simple, logical specification of formatting rules in a hierarchical inheritance fashion, Elkera has overcome the limitations of Word and WordPerfect as rendering engines with absolute indentation instead of relative indentation of text blocks. Combine this with a much more disciplined approach to layout specification, which has lead to very minimal changes in South Australia, and Elkera believably promises a very light maintenance burden. Arguably, South Australia has adopted a much simpler print specification but this impacts the size of the initial specification and development and not necessarily the effort required for ongoing maintenance.

Many of the typographic features in an XPP stylesheet can be easily changed by point-and-click activities within XyView. The stated position of XyVision was to provide initial configuration and training and let PCO refine and manage the stylesheets going forward. While this seems attractive at first, the difficulty of the macro language and its non-obvious control structures will limit stylesheet maintenance to IT staff in ways that the Elkera solution will not.

While the promise of an XML stylesheet language for 3B2 looms tantalizingly near, time constraints on this current evaluation mean that we must restrict ourselves to tools currently available. While the language for manipulating control in 3B2 is more intuitive than that for XPP, there is no corresponding GUI for manipulating the simple controls. This effectively limits ongoing maintenance of stylesheets almost completely to IT staff.

4.6.3 Production of annual volumes and reprints

Elkera demonstrated to both InQuirion and PCO the ability to automatically compile indexes to Annual Volumes and create the annual volume from a set of XML Acts. Last year's annual volume was compiled from scratch as a single Word document from approximately 80 XML documents in front of us in less than 10 minutes—a task that currently takes NZ PCO and Legislation Direct approximately 3 months! While both 3B2 and XPP can read in multiple XML documents and compile similar volumes, much of the configuration tools for South Australia could be directly adapted to the New Zealand environment. This would not require any significant DTD changes. The index material could even be in well-formed XML without a DTD.

Because ArborText rendering engines using FOSIs do not support producing a single document from multiple XML input documents, annual volumes in the ArborText solution would first require the creation of a single XML document for each volume. No DTD, editor configuration or transform currently exists to support or perform this task. It was proposed that this task be largely manual although the Elkera solution demonstrates that it can be automated.

4.6.4 Other output formats

Many drafting offices providing web access to legislation are asked to provide legislation (including draft, final and consolidated legislation) in a word-processor format (typically MS Word). This is not a current requirement for PAL but it is likely to emerge after the PAL website is launched. The current solution provides no mechanism to do this. The ArborText products have a Word import and export facility that is being used to migrate commentaries prepared by the Office of the Clerk but the current configuration does not import the bulk of a Bill or Regulation into XML nor can it export to Word. In order to support either of these modes significant mapping between XML and Word styles would be required. This is completely independent of the FOSI (or XSL-FO) stylesheets.

An automatic output of the Elkera solution would be an RTF document that could be loaded into either Word or WordPerfect by the user community. All other solutions would require a separate transform to produce RTF for the website.

4.6.5 First on page issues

One advantage of the high-end publishing systems such as 3B2 and XPP is the ability to modify vertical space above for the first item on a page. This allows aligned page tops to be produced (their vertical justification capabilities allow aligned page bottoms as well). Word and WordPerfect are somewhat more limited in this respect. To achieve the same end, a macro would have to be written to run through the document and standardize the spacing above the first block on each page. This macro could also be written to do page bottom alignment as well but this would make the macro a lot more complex, prone to error, and significantly slower and would not be recommended.

4.7 Economics

The existing ArborText solution still has a large number of outstanding defects many of which would need to be addressed to be acceptable for production. To provide a maintainable set of stylesheets, a substantial re-write is proposed to take advantage of inheritance and there are still elements to be mapped particularly for Annual Volumes and reprints.

To put E3 into production will also require additional work on the Java glue code into the CMS. Although PCO were advised to purchase an E3 licence which appears not to have been part of the system deployment, they would need to purchase at least one more E3 licence and possibly an Adobe Distiller Server licence.

Based on the complexity of the DTD and the example documents provided to them, the other vendors made initial estimates indicating that 6 to 10 weeks of effort would be required to produce stylesheets and integrate their rendering solutions with Epic and the CMS. Based on InQuirion's experience of producing stylesheets in a legislative environment, these estimates are optimistic but not unreasonable. Of course, they all have licensing costs as well. These time frames assumed a completed output specification which is advisable regardless of the rendering solution selected.

The 3B2 solution appears to offer the least value for money with the highest licence costs with no clear advantage in functionality.

XyVision have proposed very aggressive pricing but the maintainability of their stylesheet solution and the short time allowed for configuration without a complete lay-out specification step may leave PCO with considerable work to complete the stylesheets themselves.

Elkera proposes first to provide a thorough lay-out specification (which should have been done together with the original document analysis). Even if this cost in time and expenditure is higher than the ADG solution, the long term maintainability of particularly an Elkera solution, the benefits of simplified annual volume production and the possibility of integrating the numbering and cross-referencing tools already developed make this solution extremely attractive for the contribution it makes towards Phase 2 activities. Elkera's reputation for delivering on-time and on budget and their willingness to provide fixed-price quotations makes them extremely attractive. Regardless of the rendering solution selected, a lay-out specification prepared by Elkera would be a valuable asset to ensure clear communication of requirements and acceptance criteria.

The ArborText solution (at least with PrintComposer instead of E3) is currently delivered and meeting a substantial proportion of the requirements. The limitations are known and have been largely addressed. This should allow more accurate estimates of effort and elapsed time to provide a complete solution than with the other solutions. While this may prove more costly than other alternatives, unexpected problems are less likely and certainty is important at this point in the project. Improvements to the development and delivery processes should largely address the remaining concerns of PCO.

5. Conclusions

This review considered only replacing the rendering component of the system. It was assumed that the selected CMS (Documentum) and authoring (ArborText Epic Editor) platforms would be retained. On this assumption, FOSIs would still need to be maintained for screen views while editing documents regardless of the paper rendering solution. This means that a FOSI rendering solution is an advantage because it does not require additional technology acquisition by PCO. However, PCO are not using Epic as a WYSIWYG editor. Therefore screen stylesheets need not track print rendering directly. In fact, they are deliberately different in some places in the current solution. While the rendering solution must map every element to appropriate rendering, it is quite acceptable for unusual markup not to be mapped in the editing environment.

At the time the Technical Review was completed, InQuirion had strong reservations about the ability of PrintComposer to support the current rendering needs of the PCO, let alone the future needs. ADG and ArborText have worked hard to address the concerns expressed in that report. While E3 is fundamentally the same rendering engine technology, it provides a more appropriate platform for multi-user access and delivers bug fixes, improved performance and a more appropriate licensing model to the use proposed by PCO.

While the rendering requirements of PCO are well within the capabilities of highend publishing systems such as 3B2 and XPP, many of the maintainability issues already exposed by the current PrintComposer solution would be as bad or worse. Both would require in-house IT specialists trained in the product for ongoing maintenance and support. Relying on remote consultants would be too risky for black-box rendering.

While the Elkera solution at first glance looks like a low-end solution, the research and development cost sunk into either Word or WordPerfect would be many times greater than the other alternative rendering solutions combined. Many jurisdictions are currently using Word to deliver camera-ready legislation including Western Australia, Northern Territory, Victoria, the ACT, the Australian Commonwealth, South Australia, and Tasmania (the latter two from XML or SGML source documents). It is now a serious rendering solution and WordPerfect has always tracked pretty closely in capability with Word—leading in some areas and following in others.

Elkera's development approach using a Java platform, separating numbering tools into separate components to ensure reuse, and empowering users to maintain their own stylesheets has elegance and simplicity. Other solutions may hide the stitching together of underlying components, but it is there in each of the other products nevertheless. Elkera XML Print has the obvious advantage of last resort that, if the automatic rendering process produces a slightly wrong result, PPU can manually fix it in Word or WordPerfect and return to the stylesheet or rendering application once the immediate urgency of getting the document published has waned. This comfort was crucial to both South Australia and Tasmania going into production with structured markup solutions to produce Bills. Neither made much use of it, but it is there if they need it.

Elkera delivers not only applicable technology but significant project experience with end-to-end XML publishing systems with particular experience in legislative drafting environments (including the ACT, NSW, and South Australia) with a trackrecord of on-time delivery of solutions exceeding customer expectations. Even given the small size of Elkera, subject to financial viability assessment of Elkera, InQuirion believes that they represent the lowest risk path to a positive outcome for the rendering solution for PAL and can provide additional benefits in other areas of the project.

Choosing an Elkera rendering solution without an Elkera authoring solution would require maintaining stylesheets for screen and paper in two different stylesheet languages. While the Elkera authoring solution has significant capabilities with respect to selection of the next tags and automatic numbering that might put it at an advantage to the current editing solution, review of the selection of authoring platform was beyond the scope of this report.

InQuirion believes that it is possible to deliver a production system to support PCO's requirements using an upgraded Arbortext rendering platform (E3) and Format Output Specification Instances or FOSIs, If the ArborText authoring platform is retained, it is highly desirable to continue to use a FOSI-based, ArborText product for rendering. With these assumptions, an E3-based solution is preferable, but the Elkera solution should provide a fall-back position.

In order to have confidence that the solution will deliver to these requirements, it would be prudent to prepare a comprehensive set of print output specifications and matching example documents, and to adopt a more iterative, integrated, and collaborative approach to the design, development, and testing of stylesheets.

6. Declaration of interest

In addition to the interests declared in the original technical review, InQuirion and its predecessor, the Multimedia Database Systems group within RMIT, have discussed at various times partnerships with Elkera, XyVision, Allette Systems, and 3B2. At the time of this report, none of these discussions had proceeded beyond initial exploration and InQuirion has no financial interest in or special obligations to any of these organizations. On the basis of familiarity with work done by ADG with Tenix Defence Systems, MDS provided informal endorsement of them as suppliers of Adobe FrameMaker software and related services to New South Wales Parliamentary Counsel Office. Allette was and remains ADG's major competitor in this area.

Footnotes

¹

Originally defined in US Defense standards MIL-HDBK-59A [28 Sep 1990] (superseded by MIL-HDBK-59B [10 Jun 1994]), MIL-HDBK-28001 [30 Jun 1995], and MIL-PRF-28001B [20 Apr 1995] (superseded by MIL-PRF-28001C [2 May 1997]) Appendix B.

²

Note that the PAL website makes some use of CSS in rendering the HTML in the web browser.

³

Note that the Epic products have support for XSL-FO also.

⁴

Note that the Annual Volumes of Statutes and Regulations, although usually published as a number of volumes of around 1000 pages each, in total would regularly be more than 2500 pages. Timeliness of production of these volumes is much less important. The current process takes around 3 months to finalize these documents.

⁵

This can be done by "tweaking" the PrintPreview which inserts appropriate processing instructions. The XML standard requires that processing system-specific information should be stored using processing instructions. The interpretation of these processing instructions is up to the specific system. What this generally means is that processing instructions are specific to a particular technology and are not portable to either the web transformation or across different technology vendors. Polluting the long-term repository of legislation with these processing instructions should only be used as a last resort.

⁶

During the evaluation, both E3 and PrintComposer exhibited line numbering that restarts in the middle of the page (leading to multiple lines marked with the same number on the same page), ghosting of numbers near equations (possibly caused by the proprietary processing instructions to tweak spacing in tables used to represent equations), and numbering continuing over page breaks.