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.
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].
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.
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.
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.
Synopsis: There is a requirement from the aerospace industry to be able to simulate motion of current along a wire or fluid through a pipe in a CGM.
Discussion: Example use cases include, not only highlighting flow along an electrical wire, or flow through a pipe, but also the direction of that flow. 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 is TBD, but will likely involve some subset of those identified in [6].
Synopsis: There is a requirement from aerospace to be able to show movement in a CGM.
Discussion: Example use cases include physical transformation of a set of graphical primitives defined as an application structure, including movement of an APS along a simple path, rotation of an APS, and moving an APS to a new location. 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 and multiple copies of the geometry in different APS structures. More options would be available more efficiently if geometric transform of APS were possible.
Resolution: 2.1 should provide for geometric transform of APSs, by DOM/XCF Style Property and/or a new APS Attribute [TBD]. Requirements discussion indicates it should be available as a matrix transform, and/or as a collection of convenience functions for the transform components -- translate, rotate, etc. [Requirements for addition/composition of transforms TBD.]
Synopsis: The aerospace industries have an extensive inventory of static CGM images and in tandem with future requirements, require the ability to show basic movement and animation in these or new CGM files.
Discussion: Example use cases include the following: flow along an electrical wire, flow through a pipe, movement of circuit switches or the physical transformation of a set of graphical primitives defined as an application structure, including movement of an APS along a simple path. This basic movement or animation of primitives would add visual value by enhancing understanding for the technical user and giving greater utility of CGM files in a Training environment. An inexpensive and low quality "step animation" can be achieved using keyframes by the above mentioned DOM-script manipulation of some visual and geometric style properties. Animation of higher quality, using timebased methods, that are 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.
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. For example, the same CGM file may be used in a Windows, Unix, Linux and Java environment, with an accordingly different set of available system fonts. 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 way to specify font mapping.
Synopsis: There is a requirement to be able to control the rendering style 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 standardize a way of specifying defaults, e.g., something like a preferences file. Exact set TBD, but will likely involve some subset of those identified in [6].
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...).
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.
Synopsis: For users to do more useful transforms (see Requirement 3.5), information about an APS' position and dimensions are needed.
Discussion: Early practitioners of WebCGM DOM programming applications have identified this utility inquiry method as a valuable asset in their applications. Bounding box extents would suffice. It would allow users to determine center points, corners or other points of interest.
Resolution: 2.1 should define a getObjectExtents method.
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.
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.
[1]
WebCGM 2.0:
http://www.w3.org/TR/2007/REC-webcgm20-20070130/
or
http://docs.oasis-open.org/webcgm/v2.0/OS/webcgm-v2.0-index.html
[2]
WebCGM 2.0 Requirements: http://www.cgmopen.org/technical/WebCGM_20_Requirements.html
[3]
Clearwater "future thoughts" brainstorming: http://lists.oasis-open.org/archives/cgmo-webcgm/200611/doc00001.doc
[4]
Detailed 2+ requirements sort: http://www.oasis-open.org/committees/download.php/24997/WebCGM_2%20_Requirements.html
[5]
Initial 2.1 scope commitment: http://www.oasis-open.org/committees/download.php/25856/20071024_WebCGM_TC_Telecon_minutes.pdf
[6]
Style Properties: http://www.oasis-open.org/committees/download.php/25742/Attributes_Table.doc
[7]
OASIS WebCGM TC home: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cgmo-webcgm
[8]
W3C WebCGM WG home: http://www.w3.org/Graphics/WebCGM/WG/