The Potential of eXtensible Markup Language (XML) within the Aeronautical Framework

1. Introduction

1.1. Aircraft Technical Publications context

Each commercial aircraft is sold with a set of documents, used by the airlines to maintain and operate their aircraft and train their personnel. These documents are known as technical publications. EADS Airbus SA is responsible for producing all the technical publications delivered with aircraft. Technical publications are produced in a very exacting context:

• technical publications volumes are huge: for instance, for an Airbus A320, the documentation represents 1.2 gigabytes of data in 39 different manuals.

• technical publications produced for each aircraft are technically different and depend both on the aircraft and on the airline concerned.

• revision frequency is every three months on average.

• the documentary volume regularly increases because of the increase in the aircraft population.

• publications contain complex technical data, text and illustrations.

• publications are inter-referenced to a high extent.

• despite information duplication within the various manuals, consistency of the information has to be ensured.

• the content, layout and formats are regulated by the ATA 2200 specifications.

Because the information contained in the technical publications is used for maintenance, training and operation of the aircraft by the pilots, its content and meaning are very important in terms of operating costs and safety and it is mandatory to ensure that they are correct and pertinent.

To address all these issues, the production of the technical documentation has been automated. In most domains, this automation is based on the use of a documentary repository containing the information required to produce the documentation. The information is stored and managed in the form of documentary units within a database system. Production processes collate these units to produce the final documents. Using this repository allows separating contents (documentary units) from documents, running configuration management, eliminating data redundancy by managing reuse of data and automating production processes. The processes described here took great advantage of the use of structured documentation concepts, but at a time when SGML had not yet been published.

1.2. EADS Airbus SA and SGML

Since then, the SGML format has been imposed by the regulations drawn up by the ATA as the documentation exchange standard between aircraft manufacturers and airlines. The choice of using standards has been guided by the wish to ensure the longevity of the data, their interchangeability and their processing by airlines and manufacturers (for instance, creation of job cards from the maintenance documentation), by making them independent of the tool vendors.

In terms of documentation production, the first SGML technical publication was released in 1993. Our SGML publications are produced by different means (native SGML production, conversion from Airbus proprietary format, etc.) depending on the kind of manual produced. In terms of documentation utilization, EADS Airbus SA proposes a set of software, called ADOC Family, which enables aircraft documentation delivered to airlines to be integrated into their own information systems.

1.3. Possible future improvements

To cope with the SGML constraint and the evolution of documentary technologies, EADS Airbus SA is involved in research and prospective activities in the electronic documentation field. These activities mainly consist in studying new standards and technologies related to electronic documentation, in order to evaluate their potential use in the aerospace field. Such research activity development aims at preparing future aircraft documentation and related technological evolutions in three domains: standardization, documentation production and documentation utilization software development. A major part of this activity deals with the XML standard and all its related technologies.

This paper will present our long-term statements on XML and related technologies, especially with content management in mind. These statements are the result of the prospective studies described above.

2. Aircraft technical documentation: main impacts of XML growth

In this part we will discuss the potential benefits of XML, before presenting the risks and opportunities induced by its possible use within the aircraft technical publications framework.

2.1. XML : a wide range of benefits

XML comes up with potential advantages and power. We list in this section the main advantages we have identified as brought by the XML standard.

2.1.1. Comparing XML to HyperText Markup Language (HTML) and SGML: structure plus web capability benefits

At the beginning, XML was presented both as an enhanced HTML and a SGML subset. In fact, XML has taken and integrated the best from both standards to produce a standard which is more powerful:

• Structuration capability of SGML: SGML enabled document structure to be described and shared by means of generalized tagging. HTML defined a specific set of tags, which became limited and insufficient as HTML was used more and more for Web applications. XML, as SGML, allows individual tag sets to be defined in order to meet all specific requirements.

• Web capability of HTML: The success of HTML was mainly due to the simplicity of application developments, lightweight clients and the Web environment capabilities. On the contrary, SGML, despite its power, was complex to use (training, heavy development, expensive tools). XML proposes the use of the same Web mechanisms (even enhanced) as HTML and simplifies some aspects of SGML which induced tool complexity (inclusion/exclusion, mandatory Document Type Definition (DTD), etc.).

As a result, XML is a standard that not only permits data exchange and browsing, but also takes full advantage of structured contents in Web-based applications.

2.1.2. XML tools and market opportunities

XML is spreading all over the "world" and is used in an ever increasing number of areas (data model exchange, wireless applications, news industry, etc.). Therefore, the XML market is much larger than the SGML one, which was only dedicated to structured documentation. Consequences of that are quite immediate:

• numerous tools and vendors will be available,

• tools will be cheaper and more popular,

• continuity of vendors and tools will be more effective,

• choices and capabilities will be extended.

This market positioning makes the "XML-choice" easier to defend than the SGML choice which required the use of costly tools and manpower.

2.1.3. XML Family opportunities

The last advantages we want to talk about are the ones brought by the "XML technology". Indeed, XML is coming with a lot of related standards which will allow and help using it in various application fields. We distinguish three categories with respective objectives:

• Applying style to XML contents: We have in mind XSL Transformations (XSLT), XSL and Cascading Style Sheets (CSS). These "style" standards make XML viewable in many applications without any modification, as they capture the style specification in a neutral way. Moreover, XSLT brings the power to transform XML structure into another structure depending on, for instance, the type of consultation devices available.

• Handling and manipulating XML contents: Indeed, both DOM and Simple API for XML (SAX) offer the capability to write easily XML-aware applications without having to write the basic functions to manipulate structured data. Besides, the written code is quite independent from the software used and therefore reusable.

• Extending XML: XML is becoming widely used and as a consequence, limitations inherited from its ancestor SGML are often encountered. Some related standards are defined to provide the missing capabilities. The XML-Schema definition will allow the definition of more sophisticated data models that were non-reachable when using DTDs, despite the fact that they were needed by applications. Namespace definition brings the capability to mix XML contents with each different rule: for instance, you can have XML, XSLT and Scalable Vector Graphics (SVG) contents mixed up in the same file.

To sum up, a lot of XML-related technologies are available and they will help XML to cover a larger scope of industrial needs.

2.2. XML and Aircraft technical publications: major stakes

2.2.1. Niche SGML market versus mainstream XML market

The XML market is larger than the SGML one and has many strong impacts on the "old" SGML market. Indeed, many SGML-aware tools have followed the "XML way-of-life" and evolve now only to provide better XML support. The new emerging XML products do not implement SGML at all, but only XML. In the same way, existing major products such as Documentum or Oracle which look to provide structure capabilities do not support SGML but only XML.

As SGML data has been delivered for a long time in the aircraft technical publications domain, many information systems are SGML-based. These are today well established and meet user requirements. However, they can encounter problems related to the disappearance of some SGML tools (e.g. Balise). On the other hand, evolving towards XML-based systems may lead to new developments, use of different tools, process updates, training, etc.

This market evolution has seriously to be taken into account, especially when specifying new projects and choosing new tools. For these new projects, XML seems to be the best choice, but we will see later that in our specific context it is not so simple.

2.2.2. XML capabilities for On-line and Web-service applications

It seems obvious that the aircraft technical publications domain could benefit from the advantages offered by XML. On-Line digital data deliveries might become more and more popular and progressively replace paper. This opportunity should provide the people concerned with a better access to the information they need and a better interoperability between their applications: e.g. interfacing browsing application with spares purchasing systems.

With regard to market orientation, and as far as new production systems are concerned, an XML choice seems to be better than an SGML choice. We have performed many prospective studies in order to validate (or not) this feeling. And this research work raises some issues. These issues are mainly due to a wish to use XML within the whole technical publications process (from production by manufacturers to use by airlines) and not only for Web browsing as in conventional XML applications. In the next section, we will present two of these issues.

3. Going towards XML in a total production process: some issues to be solved!!

The market orientation around XML and SGML, presented above, could lead us to base our new publication systems on XML rather than on SGML. Research activities performed to prepare for such a strategy, highlighted some issues. These issues are mainly due to the way we use SGML and the limitations XML give to it. We have particularly studied two of them which deal first with inclusion/exclusion and second with entity management.

Although these issues have been identified in our specific domain, they show that implementing total XML-aware publication systems rather than SGML ones is not so easy. Actually, the difficulties encountered with XML are mainly due to both its youth and its high Web orientation. Until now, XML is mainly defined for meeting Web browsing application requirements and not whole publication process requirements including authoring, information management and production needs.

3.1. Inclusion/exclusion mechanisms

Inclusions and exclusions are part of the set of SGML mechanisms which are not supported by the XML standard. Anyway, these both mechanisms are used in the aircraft technical publications context, mainly in ATA exchange DTDs but sometimes within internal production DTDs too.

3.1.1. Inclusion utilization

ATA DTDs, defined for exchanging aircraft technical publications between manufacturers and airlines, fully use SGML inclusion/exclusion capability.

Inclusions are used for modeling the possible insertion of a specific element anywhere in a whole tree structure. This modeling technique is used when explicit insertion rules may not be exhaustively defined.

In ATA DTDs, the inclusion mechanism is mainly used for text revision marking and floating effectivity.

So, today, translating SGML ATA DTDs into XML, while exactly maintaining equivalent model capability, is impossible. DTDs could be re-designed inserting floating elements only where allowed. But existing SGML element insertions anywhere may not be translated into XML.

3.1.2. Exclusion utilization

At the opposite, exclusions allow restricting an element content model by excluding some elements from its entire structure tree.

This mechanism is often used to customize a generic low level element (for instance a paragraph) by restricting its content model in a specific context.

For instance, the following chunk of SGML definition restricts PARA content model in WARNING where all technical data are forbidden (such as CB or PANEL).

<!ELEMENT L1ITEM - - (PARA, WARNING*, LIST2) >
<!ELEMENT WARNING - - (PARA) -(CB | PANEL) >
<!ELEMENT LIST2 - - (PARA)>
<!ELEMENT PARA - - (#PCDATA | CB | PANEL)*>

As the XML standard does not support this exclusion mechanism, we have to find alternatives if we need to express this kind of restriction constraints.

For the above example, a solution is to define a new specific paragraph model for use in the element WARNING; call for instance PARAWC where no PANEL and CB elements will appear. But a problem occurs if the WARNING model is richer and includes LIST and NOTE elements for example. New specific LIST and NOTE elements, called LISTWC and NOTEWC for instance, will have to be defined.

In an industrial, complex DTD, such a solution quickly leads to heavily increasing the number of elements. Although this solution seems to solve our problem, it forces us to use a less modular modeling approach; and DTDs may therefore become very difficult to maintain. Besides, we have chosen a simple sample to illustrate this problem. Due to deep element embedding, cases may exist where the alternative is more difficult, even impossible, to find.

As a conclusion, modeling such restrictions on elements is not critical at exchange level. XML exchange DTDs do not need to translate them and therefore may permit rich and large low level elements everywhere, as in the following XML example.

<!ELEMENT L1ITEM (PARA, WARNING*, LIST2)>
<!ELEMENT WARNING (PARA) >
<!ELEMENT LIST2 (PARA)>
<!ELEMENT PARA (#PCDATA | CB | PANEL)* >

But these restrictions are crucial during the authoring step, where data quality must be assured. And XML-based authoring environments may not reach this goal using authoring DTD checking capability only:

• Restrictions are modeled within authoring XML DTDs using specific elements when possible and not too heavy.

• Some specific a-posteriori controls have to be developed for the most complex restrictions.

XML exchanged instances will potentially be equivalent to the ones available with SGML, although XML exchange DTDs are more permissive than SGML ones. Controls are performed during the authoring phase, using DTDs plus potentially other kinds of checking mechanisms.

3.1.3. Schema potential opportunities

The SGML capability for supporting inclusion/exclusion is in part responsible for parser and tool complexity and high cost. It was probably taken into account during the XML design before deciding not to implement it.

But as shown in the previous samples, this decision may have a strong impact concerning migration of huge SGML systems towards XML. Exclusion capability is predominantly important for some authoring systems.

With the arrival of Schemas, the possibilities of designing complex types appear with some interesting concepts such as type deriving by restriction or extension. We hope that this emerging standard will bring solutions to cover the modeling needs, such as exclusions, that XML DTDs do not cover.

3.2. B. Entity management

The use of external entities is preponderant in the aircraft documentation context, as they appear in DTDs and in instances.

In DTDs, they permit separation of chunks of definition to obtain modular and shared sets of definitions. This provides the possibility of reusing these basic definitions in several DTDs, and synchronizing them with all evolutions of the basic element content definition. This point is very critical when the number of DTDs to maintain is high.

In instances, external entities permit sharing of information between instances, e.g. graphics, warning/caution, standard sentences, etc.

In SGML, the reference to external entities can be achieved by different mechanisms. The most convenient for maintenance and exchange facilities is the use of public identifiers combined with a catalog. An entity makes reference to a public identifier and the tools use an Organization for the Advancement of Structured Information Standards (OASIS) standardized catalog to locate the corresponding local file system. The catalog contains all the public identifiers and mapping to their local storage.

XML also allows the use of external entities, but a major difference appears in the declaration of this. As recommended in the standard, an entity could use a public identifier, but a system identifier (an Uniform Resource Identifier (URI)) is always required. This means that no mechanism is recommended for treating the entity with the public identifier. So in practice, the market tools (except SGML tools which have become SGML/XML tools) do not implement it; they only permit the development of specific layers to handle this mechanism with a proprietary catalog.

As catalog files are officially defined by OASIS, we feel it is logical to recommend their use by XML parsers and tools, with adaptations required by the new XML needs (Web context). Besides, if public identifiers were really usable, the system identifier could become optional. Today this identifier is mandatory and so ensures the resource can be found. But update of all instances is required in case of any physical storage evolution; moreover physical storage conventions need to be defined for exchange purposes.

Hopefully, there are a few initiatives that are beginning to handle this problem seriously. For instance, Arbortext Inc. has recently made its own set of Java classes available for managing entities with public identifiers.

4. Conclusion: XML foresight

After having presented our analysis of XML benefits and issues, we will conclude by giving:

• the current ATA position on the use of XML,

• our own position on the use of XML for our new production systems.

Hopefully, these two positions are consistent.

4.1. ATA iSpec 2200 committee position on XML

Aircraft technical publications interchange is regulated by the ATA organization and the recommended format today is SGML. ATA SGML DTDs have been defined for all major publications. The ATA regulation body has written a white paper, which clearly expresses the ATA positioning on XML. It may be summed up as follows. ATA members have made a significant investment in developing these DTDs, which now correctly meet manufacturer and airline needs. There are no substantial benefits from switching from SGML to XML for the interchange of aircraft technical publications.

Anyway, ATA's position concerns adoption of XML for interchange manual DTDs; it does not prevent other XML initiatives. There may be some interesting cases for using XML for web-based aerospace documents. In the same way, for new manufacturer systems, there might be good reasons, mainly market ones, to build them on XML. Moreover, SGML delivery from these XML systems would be painless.

4.2. New production systems: (SGML=XML)-based, SGML and/or XML delivery

We have detailed the major benefits XML could bring in the aircraft technical publications domain. As SGML and XML concepts are very close, these benefits are mainly due to the wide market support for XML (as opposed to SGML).

However, based on our prospective activity feedback, XML does not yet seem to be fully ready to comply with huge technical system requirements. Actually, XML was initially designed to comply with Web consultation system requirements. Anyway, solutions may be found to cope with SGML and XML differences and moreover, emerging standards such as Schemas will certainly be helpful.

On the basis of this analysis and feedback, we think that, for our new projects and applications, the best strategy consists in building XML-based content management systems (or at least, SGML with no non-XML mechanisms). Such a choice federates the following advantages:

• Flexibility, as all required delivery formats may be easily generated (SGML ATA publications or new XML contents).

• XML market benefits, as it allows full advantage to be taken of all incoming tools.

• Time-independence, as it protects from potential risks of pure SGML tools disappearing.

Design and Development by deepX Ltd.