Figure 1: Workflow Model
Keywords: Web Services, SOAP, WebDAV, Eclipse, Authoring, Publishing
Biography
Matthew Jones has worked in technical publications in the aviation industry since 1996. He began working as a document analyst for conversion projects for an SGML browser product of aircraft maintenance data. He has also worked for an aircraft manufacturer as a stylesheet developer on SGML batch composition systems for maintenance data. Currently he works as a systems analyst for Jeppesen’s general aviation text publications production department developing new publishing systems. This work comprises a wide variety of areas, including document modeling and DTD design, system design and implementation, user training and support, and creation of system and user documentation.
Biography
Bob Thomas has worked in technical publications since 1980. He began work as a technical writer in the telecommunications through 1995. At that time Bob made a career shift to information architect and software engineer specializing in automated document production systems. He has worked in the aviation industry since 2001 specializing in electronic information production systems. Bob has a B.S. in Computer Science and Mathematics.
Jeppesen is the premiere provider of aviation information for pilots. Historically, Jeppesen delivered this content on paper using print-optimized production systems. The barriers to market entry for paper-based distribution of aviation material are considerable. This fact prevented most newcomers from competing in the aviation information business. However, the digital revolution created an information marketplace where the price of entry is considerably lower. New competitors and customer demands compelled Jeppesen to re-engineer their production systems. Jeppesen’s challenge has been to implement a system that allowed it to redeploy its considerable body of aviation information as electronic deliverables. In addition to competing in existing markets, Jeppesen wanted to position itself to offer new products and services to its customers.
This paper discusses the rationale and design behind Jeppesen’s single-source publishing system.
With the business needs to single-source publishing capabilities becoming more acute, Jeppesen partnered with Astoria Software to develop a solution. The result is a system based on commercial-off-the-shelf software, XML industry standards, and open-source tools. The system incorporates the following components:
1. Project background
1.1 Production system
1.2 User community
1.3 State of content
2. Project objectives
3. System design and implementation
3.1 Workflow analysis and design
3.1.1 Production workflow model
3.1.1.1 Authoring content
3.1.1.2 Approving content
3.1.1.3 Publishing content
3.1.1.4 Workflow enforcement
3.1.2 User interface design
3.1.3 Supporting features
3.2 Document modeling and conversion
3.3 Improving technology infrastructure
4. Implementation
4.1 Overview
4.2 XML Storage
4.2.1 Selection Criteria
4.2.2 Astoria Selected
4.3 Structured Authoring
4.3.1 Selection Criteria
4.3.2 FrameMaker® Selected
4.3.3 Future Directions
4.4 Publishing
4.4.1 Overview
4.4.2 Paper
4.4.3 Electronic Flight Bag (EFB) compatible XML
4.4.4 HTML
4.5 Workflow management
4.5.1 Overview
4.5.2 Rationale
4.5.3 Architecture
4.5.3.1 Phase 1, API-based Client
4.5.4 Business Logic
5. Conclusion
Acknowledgements
Jeppesen Aviation Data Services undertook the development work described in this paper under the umbrella of the JText project. JText was a project aimed at making fundamental infrastructure improvements allowing Jeppesen to produce aviation data more efficiently and to compete more effectively in a constantly changing digital marketplace. This section describes the state of Jeppesen’s production process and personnel at the inception of JText.
Before the project began Jeppesen essentially had a manual production system. All production activities took place on the file system with the inherent flaws of lost production time due to accidental file deletions, broken references, and other assorted pitfalls. With no content management system in place, problems often arose with determining the most recent version of a document and having no ability to lock files when they were in use. There was also no ability to restrict data access to users with the appropriate skill sets.
Production tasks generally combined authoring and publishing functions in a single step. This tended to produce the expected results of an increased emphasis on format at the expense of consistently structured data.
To compound these issues, Jeppesen maintained two production organizations to support its global customer base, one in the United States and one in Germany. Over time the production processes in these offices diverged greatly leaving two offices with two distinct production systems.
These factors resulted in an inefficient production system incapable of being effectively scaled; a system in which producing multiple outputs from a single source proved difficult if not impossible.
At the beginning of JText, Jeppesen user communities lacked separation in responsibilities. Users were responsible for the technical accuracy, structural soundness, and correct formatting of documents they produced. In this situation no real workflow existed. The technical accuracy of documents was ensured by multiple inspection steps, but little emphasis was placed on proper structure.
Additionally, the user community was viewed as group of individuals with a homogenous skill set. Little distinction was made between users who had stronger skills authoring structured data compared to those who were more adept at formatting final output. Essentially, all users functioned as desktop publishers.
Jeppesen’s content consisted of a wide variety of formats created using distinct tools. Some content was maintained as SGML documents, although no single document model had been created to support all Jeppesen publications. A larger portion of Jeppesen’s content was maintained as unstructured word processing files. Some content could be re-purposed for electronic outputs, but this was the exception. These processes generally involved time-consuming conversion efforts. This situation resulted in little re-purposing of content for different outputs.
Jeppesen’s two primary authoring and publishing tools prior to the JText project were FrameMaker and WordPerfect. Both tools reinforced the priority of proper formatting of a document over its structural soundness. These tools are page-oriented making it difficult to support multiple outputs or aggregation of content. Both of these tools also maintain content as a collection of individual files, making the task of maintaining consistent structure and format even more difficult.
JText was primarily an infrastructure improvement project. It intended to address both system and organizational infrastructure by employing new technologies, user roles and responsibilities, and production methods to achieve efficiencies, improved quality, and support new product offerings.
The project addressed these overall objectives by identifying several key goals:
The design and implementation activities followed a use-case driven approach. Essential functionality and features were determined by addressing the project objectives, meeting with stakeholders, and prioritizing development activities.
The design and implementations broke down into several major categories:
Implementing the content management system and the workflow were identified as the highest priority. Functionality addressing these objectives such as defining the production workflow, identifying user roles within the system, and designing the user interface were the main outcomes of these efforts.
One of the main goals of the project was to establish a standard workflow for both production organizations. The workflow model adopted was applied to all content managed through the system. The design sessions focused on identifying the primary production functions and defining tasks that support those objectives. The resulting workflow model emphasized three primary functions, authoring structured content, approving content, and publishing final output from structured content. Approving content was further divided into two categories, approving content for technical accuracy and approving content for structural integrity.
Redefining user roles and responsibilities to conform to the new workflow was another outcome of the design activities. Each distinct function within the workflow became the responsibility of a dedicated user group with specialized skills supporting that function.
Figure 1: Workflow Model
By identifying authoring as a function distinct from publishing, the importance of content and structure over format was emphasized within the system. Previously authoring and publishing had been performed as a single step. This inevitably led to an emphasis on presentation and the content’s structure and consistency suffered accordingly. To support this new system function a task within the workflow model was created, revise document. This task had a dedicated group of users responsible for its completion, producers. These tasks and responsibilities allowed users to focus on applying structure more accurately and consistently.
Creating tasks to ensure that content is both technically accurate and structurally sound was an essential goal of the workflow model. As with the authoring activities, previous approval procedures were often combined in a single step with a single user being responsible for both the technical content and the structure of a document. The workflow model addressed this by creating two approval tasks, inspect accuracy and inspect structure. These tasks were geared towards different user groups with distinct skill sets. The subject matter experts, aviation analysts, were responsible for the inspect accuracy task, thus ensuring that the content’s accuracy is checked by those most capable. A second user group with a higher level of knowledge of the document’s structure was responsible the inspect structure task. The main goal of the inspect structure task was to verify correct tagging had been applied.
In the workflow model these two tasks are performed on every document in the system. The workflow model allowed for a review cycle for each of these tasks. Metadata was associated with the content in the form of annotations stored by the content management system allowing reviewers to note problems and return documents to the revise document step for corrective action. This review cycle required all technical or structural issues to be noted, corrected, and approved before a document can be published.
Publishing content focused on preparing the final product output. It was important to separate this function from authoring. Since no content can be modified during this step, the publishing task ensured a document’s structure was not misapplied to achieve formatting ends. As with the other tasks in the workflow, the publish document task became the responsibility of a dedicated user group, extractors. Currently this task only supports a paper output but future product offerings will inevitably include electronic deliverables.
Compliance with the workflow was achieved by creating a set of criteria for determining when a document can progress from one state in the workflow to the next. These criteria became the basis for the workflow engine. Metadata constructs, in the form of annotations, provided by the content management system software allowed users to associate processing information with the document’s content. For example, if a subject matter expert conducting an inspect accuracy review encountered factual errors in a piece of content, the system allows the subject matter expert to annotate that content. The presence of this annotation was interpreted by the workflow engine to mean there was a technical problem with the document and it should be returned to a previous state in the workflow.
Additional enforcement rules were designed to ensure product quality. These included a rule preventing users from approving their own work as well as a tool to check a document’s structure to verify it complies with Jeppesen’s markup policies. These checks are one that cannot be enforced by the document model.
The goal of the user interface design was to provide intuitive and easy to use access to content management system while enforcing the workflow model. To this end the design emphasized a user interface with different areas for distinct purposes. One area allowed users to browse the content management system to designate content to be worked on; another area allowed users to group documents together and to assign work to other users; and a third area allowed users to view all active tasks created within the system and to complete work on those tasks.
The development team planned several supporting features during the design sessions. These features aided users in completing the primary functions of authoring, approving, and publishing. These features leveraged native functions of the content management system as well as new functionality designed especially for the project. Among these features are:
Concurrent with the workflow development efforts, Jeppesen undertook significant efforts to standardize the structure and presentation of its content. The goal of these efforts was to come up with a standardized document model and set of display stylesheets for different output formats. This goal supported Jeppesen’s ongoing production efforts by standardizing structured content and its presentation, as well as minimizing stylesheet development and user training activities.
Jeppesen settled on a Docbook-derivative document model. This model included three distinct document types all using a common pool of elements. This document model supported numerous existing legacy documents as well as established aviation industry document types Jeppesen is likely to support in the future. The document model utilized modularizations and customizations to ease maintenance and support structures unique to a particular document type.
After completing the initial modeling efforts Jeppesen developed print stylesheets to support legacy documents. At the same time Jeppesen began a large-scale effort to convert its flagship document, the Jeppesen Airway Manual, to the new document model. This conversion project included efforts to standardize content and presentation of the Airway Manual to be more suitable to the new document model. Jeppesen completed this conversion effort earlier this year and is currently publishing Airway Manual textual content using the new document model and print stylesheets.
New electronic deliverables are currently under development using XSLT stylesheets to render XML content for web browsers. XML content managed in the JText system can also be re-purposed for use in tablet PCs and potentially PDAs.
The biggest component of infrastructure improvement proved to be the implementation of a content management system. After reviewing numerous content management systems, Jeppesen choose Astoria Software’s Astoria repository. Astoria is designed as a component management system optimized for SGML and XML data. This repository product provided numerous advantages to the JText project including:
Another important component to Jeppesen’s infrastructure improvement was the choice of the Eclipse Java framework as the platform for the workflow manager’s user interface. This framework accelerated development time by providing a full set of widgets and objects for use in the user interface. Additionally it allowed Jeppesen to design stand-alone Eclipse applications that can be deployed as plug-ins. This flexibility gives Jeppesen the ability to modify the workflow model as requirements evolve.
Jeppesen’s business case for structured authoring and publishing was compelling enough for the company to implement. This section of the paper describes the components that constitute Jeppesen’s single-source publishing system, and the rationale behind their selection. Additionally, future directions are also discussed.
Jeppesen’s single-source publishing system consists of the components:
An XML storage system is a key component of an XML structured Document Management System (DMS). Consequently, such a storage system should either provide or directly support a number of document management features. In a paper given at Markup Technologies 99, Arnold-Moore, Fuller, and Sacks-Davis said (1999, ¶ 3.3) that a structured DMS should have the following characteristics:
This list goes beyond what one would initially associate with XML storage. However, these capabilities are often included with XML storage solutions. Vendors whose products do not support one or more of these capabilities usually have a recommended strategy to add them to their products.
No vendors that Jeppesen knows of could satisfy all of the selection criteria out of the box. Jeppesen selected Astoria software’s Astoria Content Management system because it readily satisfies six of the eight selection criteria:
Astoria’s extensible API has allowed Jeppesen to satisfy the remaining criteria through custom programming. These criteria are:
Jeppesen needed a structure authoring tool that met the following criteria:
The three authoring tools that met these criteria were Adobe ® FrameMaker ® , ArborText Epic editor, and BlastRadius XMetaL ®
Prior to this project, most authoring at Jeppesen was done in unstructured FrameMaker ® . Jeppesen selected FrameMaker ® as its structured authoring tool for the following business reasons:
The development team disagrees with this choice because FrameMaker ® view encourages writers to continue thinking about content as pages rather than as information components. However, the team also felt that FrameMaker ® was sufficient for the time being and that it could be replaced at a later date once our stake-holders become more comfortable with structured authoring.
The development team has a desire to move to a presentation-neutral authoring tool. Such a tool should discourage writers from optimizing content for paper output.
Jeppesen intends to publish in the following output types:
All output types will take advantage of Astoria reuse links to combine XML information components into publications.
FrameMaker was chosen as the publishing tool for the business reasons mentioned in . However, this choice is only an interim solution until a business case can be put together to justify implementing a batch pagination system.
Jeppesen distributes most of its paper publishing through sheet-replacing addenda (over 1 billion sheets per year are distributed). This form of distribution increases the complexity of implementing a batch pagination system. Given that, it seemed reasonable continue tolerating the manual processes associated with publishing from FrameMaker ® and to defer implementation of a batch pagination system to a later project.
Jeppesen’s EFB uses a schema derived from DocBook. The development team created an Omnimark ® transformation program to render repository content in EFB-compatable XML. Jeppesen chose Omnimark ® because it is highly efficient and because the development staff has plenty of experience with using it.
Transformation to HTML is also done with an Omnimark ® transformation program. Additionally, the workflow manager component makes internal use of an XSLT transform in conjunction with Astoria’s web-based document comparison tool.
Jeppesen decided to create a workflow manager using Java and the Eclipse framework. The following topics provide information about that decision:
The design team decided to create a workflow manager rather than using an off-the-shelf product. This allowed for complete control over workflow manager functionality. This decision also allowed Jeppesen to take a phased approach with the design.
Jeppesen selected the Eclipse framework because it was robust enough to eliminate a substantial amount of Graphical User Interface (GUI) development. Additionally, the Eclipse’s underlying SWT and JFace framework allowed the workflow manager to have a native look and feel.
Jeppesen’s workflow manager was built in two phases. The first phase little more than a working prototype. The phase 1 goal was to get a workflow manager in place as quickly as possible.
The second phase took advantage of emerging Astoria web services features. Phase 2 also paid closer attention long-term maintenance- and extensibility-considerations. The most significant difference between the phases is that, in Phase 2, the workflow manager client treats the repository as an abstract entity rather than as an Astoria database.
Figure 1 shows the major components of the phase 1 workflow manager’s architecture.
Figure 2: Phase 1 Architecture
Astoria components
The Astoria CMS stores the structured content that the workflow manager controls. Additionally, the Astoria CMS serves as a persistence store for workflow states. The workflow manager also uses the Astoria CMS’s event queue to maintain a list of current tasks.
The workflow manager utilizes the Astoria WebDAV Server to provide a tree-view of the repository content to the client via WebDAV.
Eclipse-Based Client
The Eclipse-based client contains both the workflow manager’s presentation layer and business-logic layer.
The Eclipse framework provides the presentation-layer code for the repository content tree-view and for the project tree-view. Eclipse widgets are also used for context menus and dialog boxes.
All of the business logic communicates with Astoria through the Astoria client’s Java API. This means that Astoria client software provides the communication between the workflow client and the Astoria CMS. However, workflow users do not access the repository through the Astoria client’s user interface.
Phase 2, SOAP-based Client
Figure 2 shows the major components of the phase 2 workflow manager’s architecture.
Figure 3: Phase 2 Architecture
Astoria components
Astoria now exposes a significant part of their API functionality through their Astoria Web Services component. In phase 2, Jeppesen takes advantage of this recent addition to Astoria by replacing all client-side API calls with SOAP messages to Astoria Web Services.
The Astoria CMS is still being used for the same purposes as in Phase 1. However, the connection with the clients is no longer direct. Astoria WebDAV server is still used; although, it not shown in Figure 2.
Eclipse-Based Client
In phase 2, the client is limited to presentation. All business logic has been moved to the Jeppesen adaptation layer which resides on a server. The client continues to use WebDAV to obtain a tree-view of repository content. However, SOAP messages to Astoria web services have replaced all of API calls the Astoria CMS.
Events from the user interface are sent through a layer on the client that abstracts the repository and encapsulates all Astoria-specific code. Similarly, all data from the repository to the user interface passes through the repository abstraction layer.
Jeppesen Adaptation Layer
The Jeppesen Adaptation Layer extends the repository manipulation capabilities of Astoria Web Services. Additionally, the adaptation layer also contains the business logic that was on each client in phase 1.
Repository Abstraction
Jeppesen felt that it was important to abstract the repository because at some point it may be necessary to interface with additional repository types. In such an eventuality, an additional repository abstraction layer would be created on the client along with a corresponding adaptation layer on the server. Little other change would be required on the client.
Remote Users
Replacing the TCP/IP-based Astoria API calls on the workflow manager client with HTTP-based SOAP messages also makes remote deployment practical. Additionally, moving the business-logic to the server permits content to be inspected without sending the content to the client.
The main component of the business-logic layer is a state-transition engine. The state-transition engine ensures that all conditions have been met before a task is marked complete. The engine also initiates the subsequent task.
The Astoria CMS maintains content status through the use of Astoria’s custom annotation feature. This feature allows comments and comment-status to be attached to repository content at any level within the content structure. Users attach comments to the during inspection cycles. Comments are always in one of the following states: unresolved, implemented, accepted, or deferred.
The state-transition engine iterates through the content being revised to determine whether a task is complete and to determine what the next task ought to be. Consider the following example:
The business-logic layer contains code that enforces additional rules such as restricting who can perform which tasks based upon Astoria administrative-group membership. Additionally, an overriding rule prohibits authors from inspecting their own work.
At the completion of the JText project, Jeppesen Aviation Data Services is well-positioned to compete in the digital marketplace. The infrastructure is now in place to support single-source publishing of aviation content to print, web, and other electronic outputs. The project has also standardized production processes and organizations to improve efficiency and promote product quality. The JText system prepares Jeppesen to support new services and product offerings such as data hosting, document conversion, and remote authoring.
The system design allows for continued infrastructure improvements. By isolating authoring and publishing functionality as distinct activities, Jeppesen intends to replace the existing tools used with improved structured data authoring client applications and batch composition systems.
XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.