WebCGM 2.0 Requirements
(Revision: July 2005)

1. Introduction

WebCGM is a profile for the effective application of CGM in Web electronic documents. WebCGM 1.0 was a joint effort of the CGM Open Consortium Inc, in collaboration with W3C staff and supported by the European Commission Esprit project. WebCGM represents an important interoperability agreement amongst major users and implementors of CGM, and thereby unifies current diverse approaches to CGM utilization in Web document applications. WebCGM's clear and unambiguous conformance requirements enhance interoperability of implementations, and it has been possible to leverage existing CGM validation tools, test suites, and the product certification testing services for application to WebCGM .

The WebCGM Profile [1] specification was issued as a W3C Recommendation on 21st January, 1999. There was a second release on Dec 17, 2001 that incorporated changes dictated by errata.

Within short time, WebCGM has become the reference profile in the CGM world, and more and more other profiles start referencing WebCGM instead of developing their own profiles.

Most users of the Internet will rarely run into a CGM on a web page, however, WebCGM is used heavily in technical publishing projects around the world. It is both used as an archival format and for distribution purposes using Internet technologies. The deployment mostly happens on CD/DVD, or on private web sites, since most companies do not want to allow for casual access to their technical data.

Based on the experiences of both vendors and users of WebCGM during the past few years, a list of requirements has been compiled that justify a version 2.0 of this popular profile. Initial work has been started by the CGM Open, a member section of OASIS.

2. WebCGM 2.0 requirements

CGM Open recognizes the following requirements for a version 2.0 of the existing WebCGM 1.0 profile.

2.1 Deferred Requirements from WebCGM 1.0

Some of the requirements for WebCGM 1.0 were spelled out in "W3C Scalable Graphics Requirements" [2]. Not all of these requirements were met, because they would have required some kind of DOM access:

pick single elements
switchable layers
access to metadata

There is consensus in the CGM community that explicit mouse event handling on defined objects must be standardized. There is also consensus that it must be possible to control visibility of objects defined by application structures. Lastly there is consensus that a limited DOM capability is needed to allow for access to the metadata

2.2 Restrictions in WebCGM 1.0

WebCGM 1.0 was developed within a tight schedule. To finish the work within the given timeframe, several requirements for WebCGM 1.0 were deferred to a later version 2.0. The recommendation contains several comments regarding future work. Among others there are

Limitation to one picture per file [3]
XML companion file architecture [4][5][9]
Exclusion of graphical features [6][7]
WebCGM DOM [8]

There is a strong consensus that this work must be finished, because it is based on existing requirements that have been excluded from WebCGM 1.0 mostly for time and bandwidth reasons.

2.3 Graphical Enhancements Requirements

Restated from WebCGM 1.0, for WebCGM 2.0:

NUBS/NURBS – Requirement from aerospace industry to allow for easy use of CAD data in WebCGM files

Interpolated interior – Requirement from various industries to allow for gradient fills

2.4 Metadata and Linking Requirements

Restated from WebCGM 1.0, for WebCGM 2.0:

Visibility – Requirement from aerospace, defence, and other industries to allow for control of initial visibility of objects in a WebCGM file

Object behaviours – Requirement from all industries using WebCGM now to allow for additional object behaviours apart from highlight and view_context.

Interactivity – Need to control (on/off) the interactivity of nodes and subtrees within the graphic structure.

2.5 Internationalization Requirements

[Editors note. The authors of WebCGM 2.0 Requirements have approved and posted a clarification of the two paragraphs in this section, presented here in their original form, in response to confusion and the perception of contradictory requirements in this section (2006-04-03).]

The use of Unicode with both graphical and non-graphical text strings was allowed in WebCGM 1.0. This reqirement continues for WebCGM 2.0. There were minor errors in the specification of the sequence tail for the complete code for UTF-8 and UTF-16. This is to be corrected in WebCGM 2.0.

The internationalization of links described by RFC3987 (IRI) was discussed by the user constinuencies of WebCGM. It was determined that there is no immediate requirement for fully internationalized links per IRI. The two major constinuencies (Air Transport Association, and AeroSpace & Defence) of WebCGM apply the specification to technical illustrating. Neither of those presently allow international character sets in their linking mechanisms. Full internationalization of WebCGM, specifically including IRI, can be deferred to a future version of WebCGM (e.g., a follow-on version 2.1), and should be deferred to avoid impact the high-priority schedule requirement.

2.6 WebCGM Document Object Model (DOM) Requirements

The general requirement is restated from WebCGM 1.0, for WebCGM 2.0. Expanded details follow:

2.6.1 Motivation

An interface for programmatic access to WebCGM contents and structure, as well as facilities to manipulate a standardized WebCGM XML Companion File, were perhaps the strongest driving requirements for the upgrade of WebCGM 1.0 to WebCGM 2.0. Virtually all of the WebCGM viewer and user agent implementations had already defined and implemented a proprietary application programming interface (API) for such functionality. Such an interface is part of a Document Object Model (DOM) for WebCGM.

2.5.2 Scope of WebCGM DOM

Compared with detailed, complete DOM specifications such as W3C's Recommendation, the WebCGM DOM should have limited scope. A full DOM would support query and discovery of all objects and entities in a target content (graphic) instance, right down to the leaf nodes of the structure tree. A full DOM would also support symmetric, detailed modification and manipulation capabilities for changing the object.

The functionality available in the WebCGM DOM should somewhat more limited. The WebCGM DOM should expose the document graphic structure down to the Application Structure (APS) level -- APS's are the fundamental addressable graphical objects in WebCGM, and are the building blocks of the hierarchical structure tree of a WebCGM.

The WebCGM DOM should support transient manipulation of the APS attributes -- which represent non-graphical metadata associated with the objects -- and transient changes to presentation style of graphical objects. The WebCGM DOM therefore should provide the functionality to query and discover the structure of a WebCGM, enumerate its graphical objects, extract associated metadata (e.g., hyperlinking data) from documents, and finally provide users with with standard ways to add more interactivity to WebCGM documents than was possible in WebCGM 1.0.

The WebCGM DOM also should provide functionality for manipulation and application of standard WebCGM XML Companion Files, as described in a following section.

2.6.3 Capabilities and Usage Scenarios

The WebCGM DOM must give access to a number of useful capabilities, all of which were designated as important requirements by the WebCGM community:

language binding:

the API is accessible via ECMAScript source code in applications.

reference by ID:

a DOM user can access a single picture, layer, grobject, para and subpara node by referencing its unique ID.

reference by name:

a user can access all objects with the same value of the 'name' APS attribute (resulting in a list of nodes).

toggling visibility attributes:

user script can toggle the visibility attribute of a picture, layer, grobject, para and subpara. For example, this functionality could be used to:

hide or show certain graphical objects:
simulate multiple states of a switch (on/off):
hide or show text layers within an illustration.

enumeration of children:

a basic document traversal capability, a user can call a method to get a list of children for a given object.

metafile information retrieval:

a user can call methods to gather diverse information about the WebCGM.

CGM Version: the metafile version and the profile ID of the document.
picture info: mm size etc
layer info: id, description, name of a specific layer.
grobject info: id, name, region, viewcontext, parent of a specific grobject
para/subpara info: id, region, viewcontext, content, parent of a specific para/subpara.

modifying hotspot info:

a user can modify (transiently, for the duration of the session) the linkuri and screentip attributes of grobject, para and subpara objects.

enabling/disabling subtree interactivity:

during a session, a user can activate or de-activate all hotspots within a defined section of a WebCGM document.

modifying presentation styles:

a user can modify (transiently, for the duration of a session) via script the following attributes at the picture and APS levels: color/intensity, line/edge weight, text font size/scale factor and text font.

events:

a user can write scripts that are executed on the following events: mouseclick, mouseover, mouseout, onload, onunload. Out-of-line links are standardized using events.

2.6.4 Outside of scope

The following capabilities are not included in the WebCGM 2.0 DOM requirements;

modifying graphical data:: A user writes a script that controls the attributes of graphical primitives (lines, circles, rectangles, beziers), for example: a user changes the width of a rectangle border; or changes the fill pattern of an ellipse.
drag and drop:: A user clicks on a object and holds down the mouse button, he drags the object to a new location then releases the mouse. The object is now located at the new mouse position.
context sensitive menus:: A user performs a right mouse click on an object, the resulting action displays a popup menu.
modifying text content:: A user writes a script that changes the text content of a para or subpara.
creating a WebCGM document:: A user creates from scratch a WebCGM document using the DOM.
adding new objects:: A user appends new objects to an existing document using the DOM.
removing objects:: A user removes existing objects from a WebCGM document.
transformations:: A user changes the appearance of an illustration by making changes to the transformation of a given object.

2.7 XML Companion File (XCF) Requirements

There are strong requirements from aerospace and defence industries to standardize the definition of XML companion files such as promised in WebCGM 1.0

2.7.1 Capabilities and Usage Scenarios

Below is the list of use cases, identified as must be addressed by XML content in companion files:

Users want to maintain standard WebCGM Application Structures (APS) attributes in XML files
Users identify WebCGM objects either by their unique APS 'id' or non-unique 'name' attribute. Hence they want to associate XML data using the 'id' or 'name', whatever is important to them.
Current CGM users are limited by the fact that attributes and their semantics are specified in the respective profiles.

2.7.2 Derived Companion File Requirements

From that list the following requirements derive:

The XML file must allow for the storage of standard WebCGM attributes. A set of rules must also be defined for processing the XML companion file.
It must be possible to associate XML data with an object in the CGM document using a unique ID, or a group of objects in the CGM document using the non-unique name.
It must be possible for the user to associate non-graphics XML data with objects defined in a WebCGM document.

2.8 Schedule Requirements

Both the Air Transport Assn and the AeroSpace & Defence groups will be updating their CGM profiles to adopt WebCGM 2.0 in 2006. By the end of 2005, WebCGM 2.0 must be, at least, late enough in the approval processes as to be technically stable. The schedule requirement is sufficiently high priority that it should by default trump most other requirements -- satisfaction of other requirements in 2.0 must be compelling, if serious schedule slippage appears likely. On a case-by-case basis, schedule-breaking features will be considered for deferral to a follow-on version (e.g., a follow-on 2.1).