Dave Cruikshank

Andre DeWild

1. Comparison of intelligent graphics models
   1. The IGEXCHANGE model
   2. The GREXCHANGE model
   3. The WebCGM model
2. An architecture for WebCGM support for ATA models
   1. The XML companion file
   2. WebCGM implementation of GREXCHANGE
   3. Web implementation of IGEXCHANGE
   4. The architectural model
3. Example implementation

Comparison of intelligent graphics models

Over that past several years the ATA Graphics Working Group has been developing an intelligent graphics interchange profile (IGEXCHANGE) based on the CGM and customized to the requirements of the industry and aligned with the structural models in the ATA SGML specifications. The ATA Graphics Working Group also maintains a graphics interchange CGM profile (GREXCHANGE). GREXCHANGE has recently been expanded to include an intelligent graphics model as an intermediate step to the full intelligent graphics model in IGEXCHANGE. In 1998, The CGM Open Consortium developed a CGM profile (WebCGM) intended for web application use. WebCGM was based on the ATA GREXCHANGE profile and is now an approved specification in the W3C.

To assist in the explanation of the various intelligent graphics models, they are graphically presented as structure charts with attributes attached where appropriate. The shorthand notations cho for choice, opt for optional, and rep for repeatble are used to indicate the syntactical structure of the models. Boxes that have dashed borders are further expanded by content model. The use of the term "gdata" is to describe graphical data within the content model.

The IGEXCHANGE model

The model describe here is a very complex one attempting to capture the structural requirements of ATA documentation.

The IGEXCHANGE model structure starts at the level of an intelligent graphic sheet or illustration. The illustration has identifier and sheet numbers attributes inherited from the ATA SGML text model. An illustration is typically made up of point of reference objects (locators), various views of the component in question (details), and strings of text (paras). An optional effectivity must precede any of the other objects.

The locator object can be made up of detail objects, callout objects to support navigation, and para objects. The attributes associated with the locator are a required identifier and implied region, common name, revision date, and descriptive text. The region attribute is used to define hotspots associated with the object. Again, an optional effectivity object is allowed.

The detail object is defined recursively and can also contain callout and para objects. In addition to the attributes associated with the locator object, the detail objects can also be identified with a particular assembly or system with the ATA model. Effectivity may also be applied to this object.

Text within an illustration may contain revision indicators, customer originated change indicators, and callout objects to for navigation purposes. The content attribute on this object is available to capture the textual content of the paragraph and aid in text searching.

There are four ways to navigate with the callout object. It is possible to navigate to an internal reference within the current document, an external reference in another document, another graphical object, or any combination of the previous three based on a particular condition or context. Effectivity is again option in this object.

Further decomposition is not carried out here, but the content models of the undescribed objects follow the ATA SGML text model.

The GREXCHANGE model

In this model, rather than trying to capture the complexities of the ATA document model, a more generic approach was taken. This approach is much easier to implement and supports its primary objective, navigation.

The intelligent graphics model in GREXCHANGE is a simple recursive model of a generic graphical object.

In this model, the attributes are defined to specify more behavior than document structure. The graphical object has a required identifier and the optional attributes common name, region to support hotspots, reference locator for navigation, view window to specify initial view, string of text to be used for screen tips, and content to facilitate text searches. Like the ATA SGML text model, the refloc attribute is not further defined and resolution of a navigation action is left up to the application.

The WebCGM model

Based on the ATA GREXCHANGE model and expanded to impose some structure, the WebCGM intelligent graphics model was designed for web applications. Its semantics are well defined and its interoperability has been demonstrated by several vendors.

WebCGM starts at the picture body within the CGM model. In this model the picture body is made up of layers or a combination of graphical objects and paragraphs.

The layer is a construct that is familiar to many illustrating systems. It allows the grouping of particular types of graphical data to be assigned to a layer within the file. Its attributes are a required identifier and optional layer names and descriptions. Its content is again a combination of graphical objects and paragraphs.

The graphical object is recursively defined and can also contain paragraphs. Its attributes are similar to those defined for the grobject in the ATA GREXCHANGE model. The difference here is that the reference locator attribute is replaced by a linkuri. The linkuri specifies a web address for navigation and can also contain an address fragment for extended linking into an object.

The paragraph object in WebCGM can contain sub-paragraphs so a finer granularity of linking can be attained. For example, there may be a substring within a paragraph that is the actual callout to another object. It has a content attribute again to support text searching.

At the lowest level of the structure is the sub-paragraph, whose attributes are the same as the paragraph and may only contain graphical data.

The WebCGM model for intelligent graphics contains enough structure to identify the type of graphical objects addressed. Those graphical objects have associated attributes that determine the behavior of the graphical browsing applications.

Previous

Table of Contents

An architecture for WebCGM support for ATA models

In order to map the complexity of the ATA IGEXCHANGE intelligent graphics model into that of WebCGM, one additional concept must be introduced. Many of the attributes that are associated with graphical objects are metadata that can be carried externally to the actual CGM file. In fact, some of the attributes inhibit reuse of illustrations if they are embedded in the file.

The XML companion file

Nearly all of the attributes, including the object types, in the ATA IGEXCHANGE model can be considered metadata. CGM is a graphics language that is well-suited to modelling graphical structure and content. Consider the ATA GREXCHANGE intelligent graphics model where the attributes are id, name, region, refloc, viewcontext, screentip, and content. Of those attributes, id, region, and viewcontext are the three that truly associated with the display of the graphical object. The others, name, refloc, screentip, and content, may be metadata that is context dependent. That metadata could be encoded external to the CGM file along with the id to tie the two pieces of information together.

Using XML to capture the metadata has multiple benefits. XML tools to manage, access and update XML files are more readily available than CGM tools are. Illustrations may be reused in different applications by simply changing the associated XML file. Query functions are easier to perform against XML than against CGM.

WebCGM implementation of GREXCHANGE

Consider the following illustration.

The paragraph in the lower right quadrant contain the text "REFER TO SRM 51-70-12 (TYPICAL EXTRUDED SECTION REPAIRS) FOR AN ALTERNATIVE REPAIR TO RIB CHORDS" might be encoded as a grobject with an identifier of "acd" containing "SRM 51-70-12" as a child grobject with an identifier of "bcd" of the entire paragraph. The companion XML file associated with WebCGM for this might contain the following:

Notice that the identifiers are the link between the object in the CGM file and the XML instance. Also notice that the elements in the XML file are from the GREXCHANGE profile but the attributes available to the viewer application give a hint to its WebCGM equivalent. In addition, the elements in the XML file no longer contain the hierarchy of the CGM file structure, but are flattened out to make retrieval by identifier query easier.

Web implementation of IGEXCHANGE

Again consider the same illustration:

At the upper left corner of the illustration there is a locator with a callout as it might be defined in the IGEXCHANGE profile. In WebCGM these two objects are encoded as a grobject containing a para. The locator might have the identifier of "cde" and the callout might have the identifier of "def". In WebCGM the XML file would contain the following fragment:

This time the XML file is made up of the element name from the IGEXCHANGE profile, but contains the attributes from WebCGM. The identifier relationship is the key for the viewer. By using the element name in the XML file associated with the identifier the requirements of IGEXCHANGE can be satisfied.

The architectural model

The following is a high-level conceptual model for how a web browser, a graphical viewer, and an XML tool might interact in this scenario:

Previous

Table of Contents

Example implementation

The presentation will contain an example of how WebCGM can be applied to the ATA intelligent graphics models.

Previous

Table of Contents