Isn't SVG much more powerful than WebCGM?
Of course it is. But that completely misses the context of our overall conclusion (that WebCGM is better suited for technical graphics). The context is a specific set of requirements for technical graphics. Most of the vastly greater power of SVG is irrelevant to these specific (and modest) requirements, and in fact SVG functionality has some gaps that miss some of the requirements. WebCGM was specifically profiled to those requirements.
There are a lot more than two SVG viewer implementations
Correct. And there are a lot more than five CGM viewers also. But we are specifically concerned with plugin-type viewers, which are the component that is most necessary and interesting in real-world technical graphics scenarios. A year ago, May 2003, there were only two SVG plugins (now we identify four).
But can't you do <that> with scripting?
Here, "<that>" represents a number of difference areas in the detailed technical comparisons where SVG advocates pointed out that scripting could solve the problem: multi-links, out-of-line-links, etc. General response: The authors agree that there is almost no limitation to what you can do with scripting. However, scripting is anathema in many real world technical scenarios where graphics must remain stable, viewable, editable, and maintainable for long periods (e.g., 10, 20, 30 years). A declarative syntax solution as part of the graphic is preferable and often essential. Full SVG becomes more an operating environment and rendering toolkit than a graphical file format.
To be clear about this issue: large scale users in the area of technical graphics are adamant about not using scripts inside a graphics file. There are several reasons for this, one is that e.g. JavaScript can not be used in hazardous environments requiring fail-safe performance, e.g. in aerospace or defense. Another important experience is that graphical content per se is not easily transferred into another format without losses; presense of scripting makes it much harder yet.
The raster comparison distorts the capabilities of SVG
The updated version of the base paper attempts to clarify this critical topic. The authors admit that the 2003 paper unnecessarily confused the raster topic by not separating the arguments about the format from those about the implementations (both of which have bearing).
    * Theoretical. WebCGM integrates one or more raster images compressed with a technique from a standard list of techniques (Group 4, as well as JPEG, PNG, and a couple others) into the binary body of the picture. SVG has two options:
         1. external reference to compressed raster images from within the SVG file (PNG and JPEG are the standardize, required formats);
         2. or, embedding the compressed raster into the xlink:href attribute of the 'image' element, using the "data:" URI scheme with base64 encoding.
      #1 is unacceptable in high-volume real-world technical graphics scenarios that might involve tens of thousands of technical illustrations, each of which might have multiple raster sub-images. For #2, base64 encoding introduces a 4/3 expansion of the binary data (which might be negated if the SVG file is then svgz compressed). In limited experiments with rasterizing a typical b/w line drawing (technical illustration), we have not yet been able to get the PNG compression to be any better than about twice the size of the Group 4 compression. Further experiments are warranted here.
    * Implementations. In the 2003 paper, we mingled some data that derived from attempts to measure SVG-WebCGM comparative raster handling, from experiments with an SVG-capable illustration tool. We got vastly different results than what theory would suggest. After distinguishing the theoretical from the practical ... should this problematic implementation behavior matter? Yes. An experienced graphical-tool implementor and technical illustration practitioner were unable to get reasonable results with an industry dominant commercial OTS illustration tool. However, the implication is not on the raster capabilities of the formats, but on the maturity, completeness, and correctness of implementations (an interoperability topic, not a static-graphics functionality topic).
      In particular, the handling of black and white raster images is critical in TG, because most of the legacy data that has been scanned is pure b&w data. The deliberate conversion of such data to RGBA is not tolerable with regard to file sizes and memory requirements. A typical size could be 4800 x 3200 pixels (roughly A2 format). As a b&w it requires about 1,875 KB of memory, as an RGBA image it would be almost 60 MB.
Isn't it an advantage that SVG is clear-text XML?
Clear text is no advantage at all in real-world technical graphics scenarios. Because of the number, size and complexity of the graphics, hand-editing and even human interpretation of the graphics code (e.g., debugging) are out of the question. In fact, there are strong arguments that clear text may be a detriment -- file size, data security, etc. The fact that SVG is XML might confer an advantage for integration with other contents types, but this can also be achieved in other good ways (e.g., XML companion files). In fact, here too there are stong arguments against intermingling non-graphical contents and metadata within the body of long-lived technical graphics. (By the way, CGM also has a human-editable clear text encoding, equivalent to its binary encoding -- it is prohibited as the delivery format in all technical profiles of CGM -- WebCGM, ATA, etc.)
Doesn't (CSS) styling give SVG an advantage?
There is a strong view in the technical graphics (TG) industry that support for user-defined styling, changeable default style sheets, etc, is actually something that you do not want supported in a TG format. Among other things, it presents data integrity and security issues. On the other hand, there is some need for controlled change of appearance, e.g., for binding transient changes during interactive viewing of things like link-target highlighting. The control should not be in the hands of the user, but rather controlled by the application program (browser).
There are some rare use cases for styling though if a contractor has to deliver the same illustration in different styles to two different customers. However, this would only be acceptable if the user couldn't change it.
Aren't you confusing SVG format issues and implementations problems?
We agree that we should clearly separate the format versus implementation considerations within each topic. That said, both the format comparison and implementation considerations matter. We are looking at the question, "how do the formats measure up for application to real-world technical graphics problems today?" From the perspective of a mission-critical application, there is little difference between the format missing needed features, on the one hand, and the implementations being incomplete or broken, on the other.
Can't you use SVG <g> to achieve the effect of 'name'?
A couple of commentors have mentioned this. The answer is, "in general, no". WebCGM can tag each item in a collection of objects that aren't consecutive in the file with a common name, and navigate (link) to that collection. A SVG group requires that the objects all be consecutive in the file, which might be impossible to arrange because of the constraints of display order. Example: 5 bolts and their associated 5 nuts. If the illustration package draws then in the order bolt/nut/bolt/nut..., there is no way to group the bolt collection with a <g> and the nut collection with a <g>. Another example is where several bolts using the same name belong to different groups (<g> tags).
Isn't SVG 1.2 going to fix <that>?
Yes, a handful of technical additions to the static and dynamic functionalities will remove some (but not all) of the differences. See the tables and text in the next section. But SVG 1.2 is not finished, and won't be reach a technically stable/frozen state until later this year (2004). The new features are not uniformly implemented yet, although some prototype implementations are tracking the SVG 1.2 changes. It then becomes an issue of when the new features will penetrate and become available to technical graphics users in multiple, stable, production versions of SVG implementations.
You make it look like WebCGM was perfect, and SVG not
WebCGM is not perfect at all. There are quite a few things that need to be improved, some of them are discussed further down in this paper. Very often, the authors feel that the development on the CGM side should progress more quickly.