* 1^st DRAFT *
WebCGM 2.1 Requirements & Use Cases
(Revision: November 4, 2007)

1. Introduction
2. Strategy overview for WebCGM 2.1 project
3. WebCGM 2.1 requirements and use cases
4. Bibliography & References
5. Revision history

1. Introduction and background

WebCGM is a profile for the effective application of CGM in Web electronic technical documents. The most current version, WebCGM 2.0 [1], was a collaboration of CGMO/OASIS and W3C and was simultaneously published by both organizations in January 2007. The original WebCGM 1.0 Profile was issued as a W3C Recommendation on 21st January, 1999, followed by an errata-correcting release on Dec 17, 2001.

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 has become the reference profile in the CGM world, and with other profiles 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.

2. Strategy overview for WebCGM 2.1 project

Post-2.0 requirements discussion has been underway since the late stages of 2.0 standardization. A large collection of requirements ([3], [4]) has been examined and discussed before arriving at an agreed strategy of a 2.1 project.

The chosen strategy now is a quick 2.1 project comprising what might be called "2.0 loose ends". These were mostly items that could have been included in 2.0 if the requirements had been articulated soon enough, but were deferred because they came too late.

This is envisioned as an approximately year-long project. Indeed, the schedule is a requirement of equal priority to any of the included technical requirements. This means that an item will be considered "at risk" for deferral to the next revision if it cannot be completed within the approximate schedule.

Initial commitment to the scope and strategy of such a WebCGM 2.1 project has been made by a sufficient number of vendors to proceed with the project [5].

3. Enumeration of WebCGM 2.1 requirements and use cases

3.1 Substring hotspots

Synopsis: There is a requirement from aerospace and defense to be able to associate a linkuri to a substring.

Discussion: A simple realization of this functionality would be to allow an APS to occur within not-final text strings, i.e., to be able to APS-tag an Append Text element. This could be achieved if the base CGM standard, CGM:1999, allowed such structure. It is considered an oversight that it did not. A Defect Correction has been approved in ISO that would allow the occurrence of an APS within partial text state. [Reference TBD -- it was to have been published by end-October, 2007].

Resolution: It is believed that the ISO defect correction enables substring hotspots even in WebCGM 2.0. WebCGM 2.1 development should examine whether any restrictions need to be placed on such partial-text APSs. WebCGM 2.1 should document the capability, and informatively note the syntax restrictions following from the ISO defect correction -- middle substrings can be APS-tagged, and an artifice must be used for the tagging of initial and terminal substrings.

3.2 Text search

Synopsis: There is a requirement from aerospace and defense to be able to search for a text string

Discussion: The requirement has been variously stated as looking within a CGM file for an APS with a given 'content' APS Attribute, or alternately locating a given string within textual content (i.e., a given string within Restricted Text element(s)).

Resolution: This functionality should not be further standardized in the 2.1 DOM interfaces. Rather, it should for now be considered as "value added" from WebCGM vendors. The 2.1 specification should provide examples of how the functionality can be achieved using 2.0 features.

3.3 regex APS addressing

Synopsis: There is a desire to be able to search APS names and/or APS ids using regular expressions.

Discussion: Scenarios have been proposed that justify such a convenience method (DOM) and/or fragment syntax extension. E.g., finding all APS that have a 'name' APS Attribute with a certain name pattern. Vendors with experience allege that free software tools are available, and therefore that the implementation cost is modest.[A number of details TBD, and discussion is ongoing -- DOM method? Fragment syntax? Should it be regex matching for *any* APS Attribute type on any APS?]

Resolution: The 2.1 specification should provide further "convenience" functionality to aid finding APSs with a regex match for 'name' and APS id.

3.4 more DOM/XCF Style Properties

Synopsis: There is a requirement from aerospace to be able to show movement in a CGM.

Discussion: Example use cases include flow along an electrical wire, flow through a pipe, or physical transformation of a set of graphical primitives defined as an application structure, including movement of an APS along a simple path. An inexpensive and low quality "step animation" can be achieved by DOM-script manipulation of some visual style properties. Some of this can be done now in 2.0 with the 'visibility' attribute. More options would be available more efficiently if some additional Style Properties were DOM/XCF accessible.

Resolution: 2.1 should provide DOM programmatic access to pan-zoom, to more line/edge-type attributes, and to more fill-style attributes. [Exact set still TBD, but will likely involve some subset of those identified in [6].)

3.5 APS geometric transform

Synopsis: There is a requirement from aerospace to be able to show movement in a CGM.

Resolution: 2.1 should provide for geometric transform of APSs, by DOM/XCF Style Property and/or a new APS Attribute [TBD]. [Likely will involve a matrix transform plus some convenience functions like translate, rotate, etc. Details of addition/composition of transforms TBD.]

3.6 Declarative animation

Synopsis: There is a requirement from aerospace to be able to show movement in a CGM.

Discussion: Example use cases include flow along an electrical wire, flow through a pipe, or physical transformation of a set of graphical primitives defined as an application structure, including movement of an APS along a simple path. An inexpensive and low quality "step animation" can be achieved by the above mentioned DOM-script manipulation of some visual and geometic style properties. Animation of higher quality, more easily authored and maintained, requires declarative animation.

Resolution: Declarative animation might be beyond the timescale of 2.1, but requirements refinement and study of technical options should continue.

3.7 Font interchange improvements

Synopsis: There is a desire in many CGM application sectors to standardize methods for specifying font mapping.

Discussion: Fonts are a troublesome aspect of CGM interchange. In a typical usage scenario, a CGM is created on one computer system using a specific font and viewed or printed on another that doesn't have the font. Although WebCGM requires that FONT PROPERTIES be included, its effective use can be complex. Solutions involving embedded fonts (SVG-like) encounter issues of size, complexity, and intellectual property rights. Many current viewers have implemented font mapping mechanisms (e.g., font-substitution files). Font mapping would mitigate the problem for relatively little (new) implementation effort.

Resolution: 2.1 should standardize a method to specify font mapping.

3.8 Default Styling Properties

Synopsis: There is a desire to be able to specify default values for underspecified attribute and control elements in V1 and V2 files.

Discussion: There are a number of use cases in this item. Attributes like LINE JOIN are CGM V3 elements, therefore the line join of V1 and V2 metafiles cannot be precisely controlled. WebCGM 2.0 says that viewers should chose and use one of the standardized styles (round, bevel, mitre). The proposed functionality would enable the user to specify a particular uniform treatment in such cases. In another usage, LINE AND EDGE TYPE DEFINITION (and similarly hatch style) default setting could allow a specific exact dash style to be assigned to the generic CGM line types 1,2,3,4,5.

Resolution: 2.1 should standardized a way of specifying defaults, e.g., something like a preferences file. [Exact set still TBD, but will likely involve some subset of those identified in [6].]

3.9 z-compression

Synopsis: There is a desire in both aerospace and geophysical applications to reduce disk requirements for CGM storage.

Discussion: Case studies have shown that large-image files -- lots of color image data -- might gain a 4-5 times compression. If the data was not formatted and compressed with Tile Array upon CGM generation, it could be compressed as a whole. The needed compression software is freely available, so the implementation cost of this improvement is modest. Viewers can "sniff" to detect gzip compression, and/or they can take clues from a specific file type extension (e.g., .cgmz).

Resolution: 2.1 should include gzip compression of whole file as .cgmz (or .cgz, or...).

3.10 Clarify transparency functionalities

Synopsis: There may still be some confusion on the interaction of the various CGM elements that have some transparency associated with them.

Discussion: 2.0 included a basic clarification of the drawing model (painters model) in informative text of Chapter 2. There are numerous ways in which transparency effects can arise, and it is unlikely that vendors have uniformly implemented all of the combinations that could arise. The fact that it has not become much of an interoperability issue suggests that this area is not heavily visited in practice. Therefore it may be appropriate to provide guidelines or define limits, or at least to clarify the possibilities.

Resolution: The 2.1 project should carefully analyze the interaction/prioritization of the various transparency functionalities, and clarify or modify as appropriate.

3.11 Get object extents

Synopsis: Programmatic control of zoom effects requires that object extents be retrievable.

Discussion: Early practitioners of WebCGM DOM programming applicatoins have identified this utility inquiry method as a valuable asset in their applications. Bounding box extents would suffice.

Resolution: 2.1 should define a getObjectExtents method.

3.12 Redraw control

Synopsis: There is a requirement to delay updating of a DOM-modified image until all the modifications have been specified.

Discussion: Early practitioners of WebCGM DOM programming applications have discovered that performance of the application can degrade badly if the image is updated immediately upon invocation of the DOM functions that specify changes. Batching the changes and applying all at once can improve performance substantially. The exact set of control states is yet TBD -- e.g., 'immediate', 'no-redraw', 'full-redraw', 'redraw-changed', etc.

Resolution: WebCGM 2.1 should include a redrawControl method.

3.13 Schedule

Synopsis: This is envisioned as an approximately year-long project.

Discussion: It is believed that a carefully chosen and modest set of 2.0 improvements, with relatively high utility and usefulness, can be standardized and implemented in approximately one year.

Resolution: The schedule is a requirement of equal priority to any of the included technical requirements. This means that a technical item will be considered "at risk" for deferral to the next revision if it cannot be completed within the approximate schedule.

Following is old stuff left over from the end of the big 2+ document [4]. Mostly to be thrown out probably. Some may be integrated somehow.

2.5 WebCGM Document Object Model (DOM) Requirements

This "out-of-scope" subsection from 2.0 requirements might be interesting to read, and consider whether any of the 2.0 out-of-scope items are in-scope for 2+.

2.5.x Outside of scope

The following capabilities were not included in the WebCGM 2.0 DOM requirements. It is natural to question whether they are in 2.1 or 3.0 or "never".

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 Internationalization considerations

Discuss any beyond the already-implemented 2.0 requirements (IRI etc).

2.8 Accessibility considerations

We deferred some topics in W3C processing of 2.0, and these will almost certainly come back in any W3C acceptance of follow-on work. (Except: It is conceipvable that we could still defer for a small 2.1 that is scoped as "stuff that should have been in 2.0 but got left out because of timing.")