WebCGM   Table of contents   Indexes   An Introduction to VML
 

XML IETMs
 Chris   Wood
  Technology Manager
  British Aerospace  Military Aircraft Division
Warton Aerodrome
Preston   United Kingdom  PR4 1AX
Phone: 01772 852114
Fax: 01772 856622
Email: chris-a.wood@bae.co.uk
 
Biographical notice:
 
Chris Wood is the Technical Publications Technology Manager for British Aerospace Military Aircraft and Aerostructures. BAe MA & A designs manufacturs and builds some of the most successful military aircraft in the world and has the broadest range of weapon systems of any military aircraft company.
 
Chris has been a member of the AECMA Electronic Publications Working Group for 3 years. He is required to evaluate current and emerging technologies in the field of Customer Support, specialising in Technical Publications, to ensure that the various Project teams within BAe (Eurofighter, Tornado, Harrier, Hawk etc.) have available to them the most appropriate technology tools.
 Database Publishing Systems Ltd 
Markos, Jason
 Swindon 
 United Kingdom  
 
He has over 10 years experience as a Techical Author, and managed a large Publishing and Printing group wthin BAe for over 5 years, before taking on the role of Technology Manager.
 Jason   Markos
  Sales Executive
  Database Publishing Systems Ltd  608 Delta Business Park
Swindon   United Kingdom  SN5 7XF
Phone: +44 01793 512515
Fax: +44 01793 512516
Email: jason.markos@dpsl.co.uk
 
Biographical notice:
 
Jason Markos sells for DPSL. Far from being stuck on the phone for endless hours trying to sell software to people who don't need it, he is out visiting actual users nearly every day. Working for the consultancy arm of DPSL, his job is to understand customers' key business drivers, and see how DPSL's services can best meet those requirements.
 
Jason graduated from college having studied Business and Information Technology for four years. Working in the Projects Business Unit, his responsibilities include marketing, organising exhibitions, account management and lead generation. The Projects Business Unit specialises in providing customised applications, consultancy and system integration.
 

Background
 
Within the UK and Europe, Customer Air Forces require comprehensive Technical Publications data, covering Descriptive, Procedural and Operator (AirCrew) information to allow them to fly and maintain their Aircraft and associated equipment throughout its service life. Traditionally, this data has been delivered in hard copy form. More recently, delivery to Customers has used a number of different media, including Paper, CD-ROM etc., with the information produced and managed using SGML, organized in accordance with traditional standards (AvP70, Mil Spec etc.) and delivered using proprietary SGML based browsers (DynaText/Synex).
 
The last few years has seen the emergence of data standards that allow us to move forward from this paradigm. These standards, (primarily AECMA 1000D, AECMA 2000M, Mil-Std 1388 and XML) are now in production use within the European Aerospace Industry on it's high profile projects such as Eurofighter etc. They describe the production of data fragments (data modules) which are organized into a Common Source Database (CSDB). Delivery of this information requires the interlinking of these data fragments on the fly to produce coherent descriptive narratives and maintenance procedures.
 
Currently, engineers (author/illustrator) analyse and manipulate design data and maintenance information stored in CAD Databases, Product Management databases, LSA databases and other associated databases. The relevant information is then transferred into a CSDB, with text tagged using SGML in accordance with the AECMA DTD and images created as Vector Graphics (primarily CGM, based on a set of established rules). Additional analysis is performed to ensure the DM conforms to the delivery requirements of the Customer. Partners and Suppliers data is also imported into the database. The deliverable is a coherent database of Data Modules.
 
However, there may be inherent configuration control problems as the end deliverable is detached from source design data. In addition, whilst the process does take account of the LSA activity, it is not directly driven by it. It is hoped that the digital product environment should be able to provide a new approach to the creation, storage and delivery of DM. This will enable the data to be retained in the source databases under the control of Product Management Software thus significantly reducing through life support costs.
 
XML or HyTime mechanisms are required to manage the linking and delivery of this information, including parts data, under appropriate configuration control. This presentation focuses on the delivery requirements brought about by these technological developments.
 

Statement of Current Requirement
 
I mentioned in the introduction to this presentation that current production IETM's make use of proprietary browsers, such as DynaText etc. I would suggest that over the last few years, this has become an increasingly expensive solution to the task of electronic delivery. In recognition of this, and also bearing in mind the UK MoD's requirement to incorporate a common service-wide solution for electronic delivery of Technical Publications data, we set about initiating a pilot project along with the Air Technical Publications branch of UKMoD and DPSL to test the capabilities of XML in a real production and delivery requirement.
 
The first key objective we set ourselves was to ensure that the solution we came up with contained at least as much (or preferably more) functionality as the IETM's which are currently in service. (I don't think that Users would have thanked us for coming up with a solution based on XML that gave them a reduction in functionality compared with their current SGML-based IETM's). Therefore, we had to establish and evaluate the key features of current IETM's and set about replicating (or bettering) them within an XML environment. (The approach adopted to this is covered in more depth later on in this presentation).
 
Another key objective we established for ourselves was a potential improvement to the distribution of technical information to the front line. It is true to say that the use of CD-ROM based IETM's has brought about a significant improvement in the distribution of technical documentation. The reduction in production of hard copy changes requires fewer personnel to perform the house-keeping roles of delivery and change incorporation etc., thus reducing costs and eliminating inefficiencies. In addition, the use of CD-ROM based distribution allows an improvement in the timeliness of the information delivered. This is done by delivering fresh CD-ROM's containing the most up to date information on a regular cycle (typically 2 months). However, we recognised that if we were to eliminate the use of physical delivery media completely, then users would have access to the most up to date information possible. In order for this to be possible, it is necessary to establish an ExtraNet of information providers and users. Again, more later.
 
Having established a real time connection between data providers and users, it now becomes possible to initiate a 2-way communication capability, thus bringing about a major improvement in the turn-round of changes to data. This became our third key objective. In order to satisfy this objective, it was necessary to perform an end-to-end analysis of the current change process, involving all major stakeholders, and to initiate a process to allow on-line commenting. In addition, we wanted to set up a system whereby users would have access to a system which informed them exactly where their improvement suggestion was in the production cycle. We believe that this will give more ownership to the creaters of these suggestions, thus encouraging them to feed back their suggestions for use by the wider community.
 
Finally, in order to ensure the utmost integrity of the information delivered in this way, it was necessary to ensure all of the above occurred under the most stringent configuration control. This therefore was our fourth key objective.
 

Approach Adopted
 
DPSL and BAe recognised very early on that working with Air Technical Publications would help ensure the success of the project. ATP is ultimately BAe's prime customer for technical documentation and are responsible for signing off for all documentation and delivery systems. DPSL had recently completed building an IETM for GKN Westland Helicopters for their Merlin Project. The Merlin Project was the first UK project to be delivered with an IETM as the primary source of documentation with the hard copy used as a back up. While this was a Navy project, ATP had had a fair amount of input into this project. This background put the three parties in a strong position to build a mutually acceptable approach to building IETM's.
 
The first part to this process was to identify which of the key user requirements were the most significant to the user. We realised, that on limited budget, we had to make sure the effort was on focused on proving the most salient, and potentially difficult, points. This work was going to be used to get buy in for this technology, which compounded the requirement to show as much of the key functionality as possible, with less concern being placed on the application being 'industrial strength' or one hundred percent complete.
 
This approach was evident when the selection of the browser was made. Microsoft's Internet Explorer version 4 was chosen as the standard browser for this application. It was selected on the basis that, at the time, it was the most advanced and widely accepted web browser in a corporate environment. It was decided that the application would not have to run in Netscape Navigator, as this would add a development overhead, without providing any extra functionality. IE5 beta was available, but not fully functional, we had to establish a base level of software that would be acceptable to corporates. With this in mind we monitored IE5's development, but maintained development of the application in IE4. Windows NT4 was chosen as the operating system, this was primarily because it is thede facto standard for the UK MOD. Developing for multiple platforms, such as 95/98 or Unix, was avoided for the same reasons as avoiding Netscape. At the time the project commenced, only the XML standard had made it to being a W3C recommendation. XSL, XLink and XPointer were at the working draft stage. The approach adopted was to try and build the software utilising the standards as they stood at they time, while trying to keep an eye on where the standards were going.
 
With regards specific functionality, we looked at what had been deemed the standard functionality for an IETM, and then considered the investment required to supply this functionality. The result was a spreadsheet of the features that would become the basis for the specification for the application. This is shown below:
 
Feature Priority Effort
Graphical Navigation drill down Low Low
Table of Contents (Synchronised) High Low
Warnings, pop-up, in-line and acknowledgement High Low
Graphics (CGM 4 and CCITT Group 4) High Medium
Audit Trail Low Medium
Security/Turn Key Operation/Remove Save Low High
Maths Low High
Tables High Medium
IPC High Medium
Personalisation/Profiling Medium Medium
History Medium Low
Search Medium Medium
 
One of the side effects of going through this process was that some functionality that had previously been recognised as a standard requirement for IETM's did not even make it into the spreadsheet. Examples include the ability for end users to make annotations and bookmarks. ATP and BAe decided that annotation functionality was in fact not required, as it was an uncontrolled way of the documentation being updated with no feedback to the production cycle.
 
Generating this table helped the team to focus on the key elements of the application. Functionality that was deemed a high priority with low cost was immediately included. Those with low priority and high cost were immediately out-scoped. The remainders were then negotiated based on looking in more detail as to their inherent value and potential cost.
 

Resulting Technology
 
Once we had established the user requirements, we could then embark on building the application. The diagram below illustrates the core components of the architecture. These include:
 
  •  Database Component
  •  Web-server Component
  •  Browser Component


 
 

Database Component
 
This component initially used Microsoft Access for the database. This tool was chosen, as it is widely available and uses standard ODBC connectivity, making it relatively simple to port applications to more scalable tools such as Oracle and SQL Server (as was implemented later in the project). The data was loaded into the database using OmniMark. The data load consisted of transforming the SGML data modules to XML and interrogating key parts of the status data to populate some meta-data fields. These fields enable easy access to the data modules contained within the database, without having to interrogate the XML content at runtime. It is important to note that the entire data module is stored in one field to maintain its integrity.
 

Web Server Component
 
This component provides the HTTP connection from the client to the server. As the base operating environment is Window NT 4 Workstation, we chose to take advantage of Personal Web Server that is supplied at no extra charge. For a full intranet based delivery system, a more scalable web-server would be adopted. We later implemented this using Internet Information Server and have users access the application remotely.
 
The Active Server Page component provides the connectivity to the database, executing queries to retrieve the data modules requested by the user.
 

Client Component
 
The diagram below gives a high level overview of the browser architecture.


 
 
The client side of the application is primarily written in Java, and consists of various components as displayed in the graphic above. The DOM builder interrogates the XML as it arrives at the client and builds a DOM of the instance content. The application then uses the XML Configuration file to build a DOM of the control objects. These are the objects that give the functionality to specific elements, for example, to make warning elements pop-up during procedure navigation. For rendering, we use James Clark's XT engine, which reads the XML and XSL and renders it as Dynamic HTML. There is also an XLink engine component, developed by DPSL, which enables the application to execute XLinks. This offers functionality such as 'one to many' links.
 
As standard browser functionality increases, some of these components will not be required, for example, XT. However, due to the architecture of the client software, this component can simply be removed as native support becomes available.
 

Conclusion
 
Here we would talk about the next stages and, if you think it is appropriate, what we could/should have done with hindsight.
WebCGM   Table of contents   Indexes   An Introduction to VML