• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Fun with XSL - a case study at CHC Helicopters
 

Fun with XSL - a case study at CHC Helicopters

on

  • 2,302 views

CHC struggled to implement a CMS in many ways. One painful way was regarding XSL. This presentation describes where we came from, how we pushed through and where we're hoping to move to now.

CHC struggled to implement a CMS in many ways. One painful way was regarding XSL. This presentation describes where we came from, how we pushed through and where we're hoping to move to now.

Statistics

Views

Total Views
2,302
Views on SlideShare
2,300
Embed Views
2

Actions

Likes
0
Downloads
25
Comments
0

1 Embed 2

http://www.slideshare.net 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Fun with XSL - a case study at CHC Helicopters Fun with XSL - a case study at CHC Helicopters Presentation Transcript

  • Fun with XSL Getting content out of your CMS
  • Phase 1: The organization prepares (2004)
    • For CHC, organizational pain was the only path to the cultural level change that CMS requires
    • The solution proposal evolved and the scope of the requirements crept
    • Need a clear mandate and a supportive Executive sponsor
    • We picked Docbook over DITA simply because we got into CMS 3½ years ago
  • Phase 2: We have a CMS…now what? (2005)
    • The implementation and conversion of documents to XML got ahead of the output capabilities
    • Had a very helpful implementation coach in Jeff Hooker
    • Used Norman Walsh XSL for a while
    • Came to a crunch and we got a basic XSL that everyone used at first
  • Phase 2…continued
    • Initial XSL basics included:
      • Title page
      • Reasonable rendering of images
      • Internal links
      • Page numbers
      • Hyperlinked TOC
      • Chapters that started on odd pages
      • Provisions for a back of the book index (no tagging to make it work though)
  • Phase 2…continued
    • What we didn’t have was:
      • List of Effective Pages (LEP)
      • Change bars
      • Adequate CSS to view our in-house tags properly in our XML editor
      • XSL for anything but the most basic Docbook tags (this meant that authors could insert tags into the documents that wouldn’t publish)
      • A way of telling when the XSL had failed
      • A way of constraining what authors could pick for tags
  • Phase 3: developing a developer (2006)
    • One failed attempt to hire an XSL contract developer
    • Hired a clever fellow who quickly taught himself XSL.fo
    • He solved numerous problems and trained his replacement before he left
    • Now we have XSL for everything that authors can select as a tag. We “downgraded” to Docbooklite as a subset of full Docbook for the sake of simplicity
  • Phase 4: Gaining momentum
    • The requirements of a regulatory environment:
      • List of Effective Pages (LEP)
      • Change bars
      • (nice to have) a summary of changes since the previous revision
  • Phase 4… continued
    • Greatly complicated by the possibility of variants all on different review, revision and approval cycles
    June 2006 Canada variant January 2007 Canada variant May 2007 Canada variant January 2008 Canada variant October 2006 Brazil variant April 2007 Thailand variant November 2007 Brazil variant Time A B C D E F G H
  • Phase 4…continued
    • Current CHC solution
      • List of Effective Pages (LEP)
      • Change bars
      • Summary of changes
  • Going forward: leveraging the content
    • Next phase of XSL development is getting the content not just reused multiple places but also massaged in the process…
    • Examples and “show and tell”
      • Headings and introductory paragraphs of multiple modules in a course could create an automated syllabus
      • Headings from a course could be used to populate an exit checklist that confirms comprehension and facilitates a trainer signing off a pass/fail standing