Managing Digital and Print Deliverables for Aviation Data

1
Managing Digital and Print Deliverables for
Aviation Data

• XML 2004
• November 18, 2004
• Chip Gettinger, Astoria Software
• Matthew Jones, Jeppesen
• Bob Thomas, Jeppesen

2
JText Project Background

• Jeppesen Aviation Documentation Services (AvDocs)
  authors and publishes text and graphic content
  for pilots
• Paper documents are primary products
• Flagship product (Airway Manual) first published
  in 1940s publication more an aggregation of
  pages than a unified document
• Department maintains variety of documents
• Operations manuals
• Aviation regulations
• Pilots navigation aids

3
AvDocs Before JText

• Print product demands dictated much of
  organizational structure
• Two production organizations (USA and Germany)
  with distinct practices and procedures
• Poorly-defined production roles and
  responsibilities
• Users functioned as self-contained production
  group - serving as authors, editors, approvers
  and publishers
• Haphazard quality system in place
• Review cycles made little distinction made
  between content and structure

4
AvDocs Data Before JText

• Data set characterized by inconsistency in
  content and layout
• Legacy data maintained in variety of formats
• Multiple versions of unstructured FrameMaker and
  WordPerfect
• Structured content maintained in several distinct
  SGML models emphasizing format over semantic
  intent
• Production decisions often determined by output
  medium
• Data often finessed to conform with existing
  page boundaries

5
AvDocs Production Environment Before JText

• All production activity took place on file system
• No versioning of content
• No access control applied
• No data reuse
• Paper was only easily-supportable product
• Re-purposing of existing data for multiple
  outputs prohibitive
• System not scalable
• User training in existing authoring environments
  not easily accomplished
• Conversion of new documents difficult at best

6
Project Objectives

• Revamp AvDocs technology and organizational
  infrastructure
• Use industry standards and related technologies
  (DocBook XML, XSLT, and SOAP) to promote
  efficiencies
• Separate authoring and publishing functions
• Promote separation of roles and responsibilities
  with distinct tasks for qualified users
• Standardize production practices between both
  production organizations
• Support new product offerings through
  single-source publishing
• Develop capabilities for remote authoring services

7
More Project Objectives

• Introduce workflow model with enforcement to
  improve product and process quality
• Implement quality system to facilitate ISO
  certification
• Modularize system functionality and use
  open-source tools to promote tool independence
• Develop document model to support multiple
  document types and promote data re-use
• Promote consistency with standardized stylesheets

8
JText Heavy Lifting

• Document modeling
• Choose DocBook derivative to speed modeling
  efforts and avoid Holy Wars
• Modularized DTDs to support multiple doctypes
  using a common pool of elements
• Document conversion
• Standardized layouts to promote consistency and
  ease conversion efforts from unstructured formats
• Completed year-long effort to convert thousands
  of pages of structured and unstructured data to
  new XML model

9
Workflow Model

• Four primary roles created within system
• Analyst subject matter experts responsible for
  content accuracy, project planning and scheduling
• Producer structured editors
• Approver structure experts responsible for
  ensuring consistently-applied markup
• Extractor format authorities responsible for
  preparing product output
• Production organizations realigned to support new
  roles

10
Workflow Tasks

• Focused production groups on redesigned tasks
  emphasizing core competencies
• Revise document structured authors focused on
  creating and revising structured content
• Inspect accuracy subject matter experts
  examining technical accuracy of content
• Inspect structure tagging authorities
  validating structure and departmental policies
• Publish document formatting experts preparing
  final product output
• Inspection tasks enforced quality system
  providing multiple opportunities to check content
  and structure

11
(No Transcript)
12
Supplemental Features

• Policy Enforcement Tool
• System utility to check for compliance with
  departmental tagging policies
• Reviewing Environment
• Web-based rendering of authoring data using XSLT
• Provided simplified interface to subject matter
  experts
• Aided transition from page-based data
• Comparison Utility
• Used differencing engine to give users merged
  authoring documents with highlighted differences
• Reporting Feature
• Provided means for generating reports of system
  activity, e.g. process quality benchmarks,
  on-time delivery, etc.

13
System Design

• JText system diagram
• XML storage
• Structured authoring
• Publishing
• Workflow management

14
JText System Diagram
15
XML StorageSelection Criteria

• On-the-fly creation of renditions
• Automatic transformations
• Access control at the element level
• Access to elements (component versioning)
• Intentional versioning (effectivity)
• Human-readable description of changes
• Extended search capabilities
• Document-based workflow
• Arnold-Moore, Fuller, and Sacks-Davis (1999),
  Paper from Markup Technologies 99

16
XML StorageAstoria Selected

• Astoria Content Management System directly
  satisfied six of the eight criteria
• Astorias API and web services architecture made
  it possible for us to satisfy the remaining two
  criteria (creation of renditions and workflow)
  through custom programming
• Astoria ties storage, authoring, publishing, and
  workflow components together

17
Astoria Internet Multi-Tier Architecture
18
Astoria Configuration
19
Structured Authoring Tool Selection Criteria

• Read, write, and store content as XML
• Built-in validating parser
• Integrated display of various graphics formats
• Sophisticated table editing support (CALS)
• Integration with CMS

20
FrameMaker Selected for Business Reasons

• Existing base of FM users who were resistant to
  change
• Licenses already bought and paid for
• FUD around adopting a different tool
• Development team chose to defer this battle until
  after the system has been in place for a while

21
PublishingOutputs

• Paper (PDF output)
• XML compatible with our Electronic Flight Bag
  product
• HTML

22
PublishingXML/HTML output

• Omnimark used for transformations
• Staff has extensive experience with Omnimark
• Omnimark is an excellent tool for creating and
  executing transformations

23
PublishingPaper

• FrameMaker chosen, once again for business
  reasons
• This decision will also be revisited

24
Workflow Manager

• Collaborative effort
• Screen-shot
• Design diagram
• Design principles
• Eclipse-based client
• Astoria web services and WebDAV
• Jeppesen adaptation layer
• Multiple uses of Astoria CMS

25
Collaborative Effort

• Design team consisted of two Jeppesen software
  engineers and a software engineer from Astoria
  professional services
• Collaboration during design lead to efficient use
  of the API and incorporation of new Astoria
  functionality
• All three members of the team have a complete
  understanding of how the code works and how to
  maintain it in the future

26
(No Transcript)
27
(No Transcript)
28
Design Principles

• Extensibility It will be possible to add
  different types of repositories if they provide
  sufficient web services and WebDAV capabilities
• Encapsulation The client confines all knowledge
  of Astoria to a single class that implements an
  abstract repository interface called IRepoMan

29
Eclipse-based Client

• Programming in Java
• The client is a customized Eclipse (3.01) product
• Eclipse was chosen because it is robust and easy
  to extend
• Most GUI components are SWT/JFace implementations
• A few Astoria Swing dialogs are used

30
Astoria Web Services and WebDAV

• Eclipse client uses WebDAV to populate repository
  tree
• Eclipse client uses SOAP to talk to Astoria web
  services
• Astoria Web Services handles content update and
  retrieval

31
Jeppesen Adaptation Layer

• Jeppesen adaptation layer is a server-side Java
  application that adds the following custom
  functionality to Astoria web services
• Project-data storage and retrieval
• Workflow state-transition engine
• Project archiving and content clean-up

32
Multiple Uses of Astoria

• Authentication
• Content storage
• Persistence layer for the workflow by storing the
  following
• Project data as well-formed XML
• List of current tasks as events in an Astoria
  event queue

33
Lessons Learned

• Transition from page-based production has proved
  difficult to accomplish
• Currently transition is roughly 60 complete
  legacy data contained many artifacts of paper
  product that still must be addressed
• Changing departmental paper-production culture
  has been the most difficult mindset is slowing
  moving away from page paradigm
• Disparate development environments hampered
  efforts
• Collaboration tools would have improved process

34
More Lessons Learned

• Workflow manager tool has been well-received by
  user community
• Simplified production tasks by allowing users to
  concentrate on their specific areas of expertise
• Increased product quality and system throughput
• Aided in ISO certification efforts
• Value in collaborating
• Collaborating with vendors gave product insight
• Collaborating with business units unified
  processes and improved ownership

35
Outstanding Tasks

• Metadata Modeling
• Working on developing metadata vocabulary to
  improve paper production and facilitate new
  electronic product development
• More legacy documents to convert and manage in
  system
• Additional data modeling to support richer
  semantic document models
• Implement batch composition system
• Paper production remains largely a manual effort
• Migrate from WYSIWYG authoring environment
• Enable remote authoring capabilities

36
Thank you for your time

• Questions ?