Intelligent Graphics: Towards a viable architecture using the most appropriate standards

Maryse DA PONTE
Research Engineer, Aerospatiale Branche Aeronautique

Service A/BIS/A, BP D0611
316, route de Bayonne
Toulouse (France) 31060 TOULOUSE Cedex 03
Email: maryse.da-ponte@avions.aerospatiale.fr

Biographical notice

Maryse DA-PONTE joined Aerospatiale in 1989 and has worked in the electronic documentation since 1992. From 1994, she has been involved in the graphics area and has joined the (Air Transport Association) /AIA (Aerospace Industry Association) Graphics Working Group which is working on the concept of .

Maryse is a graduate engineer in Computer Science from the CNAM (Conservatoire National des Arts et Metiers) (France).

Lofton HENDERSON
Dir. Adv. Graphics Devt, Inso Corporation

1919 Fourteenth St,
Ste 610,
Boulder (USA) CO 80302
Email: lofton@cgm.com

Biographical notice

Prior to joining Inso Corporation in November 1997, Lofton Henderson presided over Henderson Software, Inc. In 12 years of operation, HSI specialized solely in technology, and offered a wide selection of premier products and services in that field. HSI's products were the first ever to be certified by NIST for and CALS compliance.

Prior to HSI, he was Computer Graphics Project Leader at the National Center for Atmospheric Research. He has taught and lectured extensively on related topics, and is co-author of the "The Handbook" (Henderson and Mumford, Academic Press, 1993, 450 pp.), an in-depth look at the standard and its application in the real world.

He has worked on the ANSI and ISO committees responsible for graphics standards for 15 years, during which time he has been: document editor of the 1987 and 1992 releases of the standard, as well as the in-progress 1998 republication; leader of the ANSI task group; and current Convenor of the ISO SC24/WG6 Metafiles Working Group. He has made substantial contributions to the definition of the significant industry profiles: GRexchange and IGexchange, PIP, J2008, RIF, and currently the WebCGM profile being collaboratively developed by Open and W3C.

Abstract

A need for more powerful standardized graphics has appeared in electronic technical documentation. This new generation of graphics will be presented. Several standards are candidate to specify structured graphics. The advantages and the limits of each candidate standard in the framework of the structured graphics will be discussed and an attempt to define a viable architecture will be made.

Introduction

The aeronautical technical documentation, including AIRBUS documentation, has specific characteristics. Varied (different domains, different types of information), it is also characterized by large quantities of data, numerous customisations, short revision cycles and a long life. A high level of standardisation is also needed.

The aeronautical technical documentation includes many graphics. An AIRBUS Illustrated Part Catalog can include more than one hundred thousand graphics. Their uses are frequent and varied. Sometimes, experienced mechanics only take the graphic to repair a failure. Technical documentation users also use them as a means of navigation in the large-volume documentation. In fact, graphics enable a rapid understanding of information and are an efficient means to improve the readability of information.

In order to manage all these characteristics, technical documentation is migrating to Electronic Structured Documentation which offers powerful potentialities in terms of consultation, edition and management. This migration should enable to make the most of the graphics media. However, current standardized electronic graphics are limited. They do not enable, for example, a link from one object to another object of the graphic, to permit the mechanics to find other correlated data quickly. These limitations are because they do not enable any computer processing. Applications cannot interpret objects and their related information inside graphics. Only human eyes are able to interpret them. Therefore, a need for more powerful electronic graphics has appeared.

To answer to this need, 2100 Graphics Working Group has defined the concept of " " and is proposing two solutions using and standards to specify it. In addition, standards such as HyTime and offer new possibilities which could be used for . All these standards will be analyzed to find the best-standardized way to specify structured graphics. A final architecture will be proposed to manage their use for Intelligent Graphics.

" " concept

The concept of " " defines standardized structured graphics, which could be used by applications in an interactive way. The " Requirements" specifications [IGREQ22] gives some base principles for the structuring requirements and defines the functionality that " " must support.

modeling

specifications [IGREQ22] give some basic Object-oriented requirements for structuring graphics. As the basic need is to access objects smaller than the whole picture, the picture is structured in objects, called "graphical objects". These objects are logical units, such as an engine or a locator. They could contain a graphical representation of the object and the semantics associated with these objects or it could only include the semantics associated with these objects.

To be accessible, each graphical object must be identified. A logical graphical object can have relationships to other objects (graphical or ). The semantics of the logical graphical objects, also called properties by the specifications [IGREQ22], is described via attributes. Logical graphical objects can be nested.

" " Functionality

defines four types of functionality. Three of them will be presented here. In regard of the state of the art, the last functionality, the analysis seems more difficult to be implemented today in a standard way and will not be therefore studied here.

 Intelligent Graphics 
  Navigation needs
  The first functionality specified in the "
" concept is navigation. It permits, for example, the navigation from an illustration of a component to another illustration of the same component containing more details. This functionality represents all the capabilities of browsing from a logical graphical object to another documentation unit.
  It will be done from a logical graphical object to another logical graphical object and/or textual element. For example, a fault code can refer to two figures. In this context, Out-of-line links could be useful to have easy maintenance and a common specification of links for text and graphics.

 Intelligent Graphics 
  Query needs
  The second functionality specified in the "
" concept is the query. One example is "based on a reference designator or an equipment list number, being able to access illustrations containing a particular part". This functionality represents all the capabilities of accessing a logical graphical object using query mechanisms.
  Different types of query are necessary, full text search, queries on the structure, e.g., find all the illustrations of chapter "31-30-00" and queries on properties, e.g. finding the graphical object representing the part whose part number is "D60192". Some queries mix both types.

 Intelligent Graphics 
  Extraction needs
  The third functionality specified in the "
Requirements" specifications is the extraction of data, e.g., identification of the reference designator or equipment list number associated with a component in a graphical object. This functionality will enable the end user to access the non-graphic information from an illustration. The extracted information could be or not a part of the visible illustration.
  Despite there being a subtle difference between the goals of extraction and query, in terms of exchange specifications, the extraction requirements are almost the same as the query requirements. The extraction is done by the applications after the query.

Exchange specifications

Today, the " Exchange" specifications [IGEX24] recommend two ways to exchange structured graphics, a pure solution or a mixed solution using plus . Thus, the "semantic" content may reside either in the , or in the . In the latter case, is associated with identified objects in the . The specification of this solution needs to be completed to specify the roles of each standard in a detailed way. The study of the standards will help to complete this solution.

Study of the standards

The (Standard Generalized Markup Language) enables representation of the structure in a rigorous way enabling the analysis and treatment of this structure by computers, independently of the platforms and of the software. The separation of structure and layout is one of the strong points of .

enables the definition of generic structures for particular types of document, the DTD (Document Type Definition). A markup language is built to express the different constraints existing on the structure and contents of a given class of documents. The DTD is interpretable by computers.

The standard does not define a query language. However, SDQL (Structured Documents Query Language), included in DSSSL (Document Style and Semantic Specifications Language) defines a query language well adapted for handling structured documents ( in particular).

presents some limitations for links. Links on objects are possible only in the scope of the same document. They are enabled only between special elements which have been identified as target elements (using ID(s) attribute) and special elements that have been identified as targeting elements (using IDREF(s) attribute). For external links, interprets the external document as an indivisible document, because there are no means to measure, locate and count within data. standards family tries to remove these limitations.

XLL

and

The standard (eXtensible Markup Language), based on , introduces a new type of document, the well-formed document: a structured document, which can be processed without its DTD. It makes the processing simpler.

Another standard of family, (eXtensible Linking Language) is the process of specifying high-powered hypermedia linking, and pointers to very specific locations within data. This standard has been strongly influenced by HyTime and TEI extended pointers.

The subset, XPointer provides a simple syntax for pointing to elements and other parts of documents regardless of whether they have IDs.

The subset, XLink provides a way to collect groups of these pointers to make entire links: connections between arbitrary numbers of data objects. It permits you to identify your own linking elements with any names you want, and defines several sub-types of link. The simplest link, called "simple inline" link, is a one-way link from the link's own location to one other place and works like the HTML elements. XLink also provides a way to collect links outside of the documents that they reference, the "out of line" link. XLink links can also include metadata about individual links and pointers. For example, they can specify a formal role or function for each individual end. Finally, XLink provides some very rudimentary behavior control.

(Computer Graphics Metafile) is the ISO standardized language to represent two-dimensional graphics with vector or raster data, independently of the platforms and of the software. defines a functional specification, independent of the encoding of the metafiles and three types of encoding. The binary encoding is a compact encoding adapted to the large size of graphics files. As it supports compressed raster and symbols libraries, is well adapted for technical documentation.

The Application Profile (A.P.) defines how a domain uses , e.g. the Application Profile defined for the civil aeronautical domain. A parser checks the conformance of the metafile to and to the Application profiles. This latter which also enables definition of semantics specific to the domain will become more important with "structured graphics". However, as the Application profile is not written in a computer-understandable way, tools are not able to adapt automatically to all profiles.

The APplication Structure (APS) element enables the grouping of graphical elements into logical objects meaningful to and accessible by applications. APS are based on the mark-up principle and delimited by mandatory tags. The APS has a type which permits classes of APS to be defined. It may be described by one or more attributes, which provide the capability to associate non-graphical information with the logical graphical object. APS enables the metafile to be structured in a hierarchical structure. The WEB profile, recently defined by Open and W3C specifies interactive graphics with APS.

Two models of APS are available, the embedded APS which includes the graphical primitives of the objects and implicit boundaries and the overlay APS which includes explicit boundaries of the object. The embedded APS offers possibilities that are more powerful: no data redundancy, exact boundaries and easy maintenance. The overlay model is useful for legacy, and raster data.

APS are specified and standardized by means of the A.P. However, today, no formalism exists in for describing content model and APS relationships, such as DTDs. No occurrence symbols, no connectors and neither reduced possibilities are available for typing objects. Specifying at least the metadata content models should be considered as a high priority requirement for the widespread use of structured graphics profiles.

No standard way is defined in to specify the links between graphics or between graphics and other types of data. The only thing useable by a link application is the capability of defining an ID for a given APS. This is a step forward to the link capabilities. However, a uniform solution is necessary.

No query language is available today to manipulate data and in particular Version 4 data.

The choice of standard

The study of the standards has led to the following conclusions. / is a well-suited standard for describing structured documents. Regarding , it is obvious that it lacks graphic specifications to handle graphics. is a well-suited standard for describing 2D graphics despite some standardized formalisms are missing to handle structure. However, each standard offers part of the required functionality. If we use both standards, where is the frontier between use of each?

Structure model

Studying structured graphics has highlighted the need for a structure model. The study of the requirements and the standards , and has shown that using something equivalent to a DTD to define a structure model of a graphic is necessary. As today, does not offer a formalism to define a complete structure model, it seems that / DTD is a good means to describe this structure. As specified by the principles, this structure model will not be mandatory for consultation.

Due to the growth of , we think this standard will make numerous tools available and will be the substitute for many uses of . Therefore, we recommend that every new feature defined with must be " -compatible" (conversion to must be possible at consultation).

Specify and Structure graphical data

is already known as a powerful standard for representing graphics. Although some attempts have been made to describe graphics in , it is obvious that must be used to describe graphics. All the graphical data, such as the graphical primitives and the boundaries of the objects, will be specified with . The logical objects will be defined by using APS (Application Structure feature). For new graphics, the embedded model, more powerful, is recommended. Thus, the boundaries of the objects will be automatically managed by the tools. The overlay model will be only used for the raster data, particular for photos and legacy .

Property specifications

Considering the current state of the art, especially the fact that has no modeling capability and the fact that we choose to use a DTD for model control we decided to use a / file for handling properties of the metafile. This file, called "companion file" will be attached to the file. The structure of the graphic, described with APS, will be duplicated in this companion. Properties will then be added to the resulting structure in this file. This companion file will enable the graphics to be checked against the model defined by the DTD.

XLL

Link specifications

Today, the most powerful standard to define exchangeable links is of the family. As has a more pragmatic approach than HyTime, it seems has a good future and numerous tools will probably be available.

Query Language

Concerning the "Data Extraction" and "Query" needs, the first step for implementing intelligent graphics is to verify that the data on which queries and data extractions have to be achieved are correctly identified. Then the query and data extraction could be performed using conventional query languages. Standards for more powerful query languages are in development in several forums, but not yet advanced enough for review or choice. In the short term, existing query languages should be used.

Conclusion

This paper has permitted choices to be made specifying a viable architecture for ". The chosen solution raises the classic issue of duplicating information. However, these choices are made in regard of the state of the art. We considered that tools are already available and that it will be easier to handle this issue than to make standards evolve and vendors implement them in a short time. Besides, we can imagine that a structure will be generated automatically from another.

But we do not forget that the environment is evolving rapidly. The evolutions of standards must be monitored.