Keywords: APPLICATION STRUCTURE, CALS, ATA profile, ATA GREXCHANGE, WebCGM, CGM, SVG, Graphics
Biography
Lofton Henderson is an independent contractor with long experience in computer graphics, and especially in Web graphics technologies - WebCGM and SVG. He co-authored the "The CGM Handbook", Henderson and Mumford, Academic Press, 1993, 450 pp. He has long experience on the ANSI and ISO graphics standards committees, and has had a role with several industry consortia defining CGM profiles: ATA, PIP, J2008, and RIF. Currently, he is co-chair of W3C's QA Working Group, Program Director and past chair of the CGM Open Consortium, a member of W3C's SVG Working Group, and a member of two OASIS technical committees, Conformance, and XSLT conformance.
Biography
Dieter Weidenbrueck is the founder and President of ITEDO Software, the manufacturer of the Technical Illustration package IsoDraw and of IsoView, the viewer for intelligent graphics. He is the primary architect of the IsoDraw and IsoView software programs. Dieter Weidenbrueck has developed a considerable experience in the field of documentation standards and is actively participating in standardization efforts concerning technical illustration. He is one of the authors of the WebCGM Recommendation. He serves as the current Chairman of the CGM Open Consortium.
In 2003, the authors set out to provide an objective answer to the persistent question: why there are two W3C standards, WebCGM and SVG, for Web-based graphics? In a nutshell, the reason has been summarized as "WebCGM for Web-based technical graphics, SVG for graphic arts and creative graphics." This simplistic formula, however, does nothing to satisfy curiousity about whatever underlying reasons and rationale there might be. The authors, both of whom are long-time practioners and product builders for technical graphics, gathered and presented data about the two formats, from the perspective of the requirements of technical graphics. The data look at both the technical match of the standards to the requirements of technical graphics, as well as considerations such as practical real-world interoperability. In the past year, the initial version of the analysis and comparison has had at least two results: technical additions and modifications to the SVG standard have been proposed, for the in-progress SVG 1.2 revision; and, various SVG blogs and other sources have disputed some of the results of the comparison study. The authors take a fresh look at the technical differences between the standards -- the gap is narrowing somewhat but not closing completely -- as well as take some time to examine some of the criticism of the 2003 analyses. In addition, an updated snapshot of the interoperability landscape shows significant new activity, although of notably different focus, around both WebCGM and SVG.
Introduction
Background
Motivation & Roadmap
Requirements
Results & Conclusions 2003
Differences in static-graphics
functionality
Differences in dynamic-graphics
functionality
Interoperability considerations
Overall conclusions 2003
Frequently Asked Questions
Isn't SVG much more powerful than
WebCGM?
There are a lot more than two SVG
viewer implementations
But can't you do <that> with
scripting?
The raster comparison distorts the
capabilities of SVG
Isn't it an advantage that SVG is
clear-text XML?
Doesn't (CSS) styling give SVG an
advantage?
Aren't you confusing SVG format
issues and implementations problems?
Can't you use SVG <g> to
achieve the effect of 'name'?
Isn't SVG 1.2 going to fix
<that>?
You make it look like WebCGM was
perfect, and SVG not
Changes to WebCGM & SVG since 2003
Dynamic & static graphics
Interoperability
WebCGM
SVG
Assessment
of Implementations
Outlook
SVG
WebCGM
Summary & Conclusions 2004
Bibliography
In 2003, the authors finished and presented work [WebCGM-SVG 2003] that had begun the previous year on a topic that had spawned much discussion and positioning, but not much objective information: why are there two W3C Recommendations for Web graphics?
At a high level, it was already common positioning in the graphics community that:
In a nutshell, the conventional formula has always been presented as: "WebCGM for Web-based technical graphics, SVG for graphic arts and creative graphics."
We then took a closer look at the distinction, by examining the requirements of Technical Graphics in some detail, and isolating where the respective language features differed about particular technical graphics requirements. Because interoperability is such a critical requirement in the technical graphics sector, we also took a preliminary look at implementations.
In the past year the initial version of the analysis and comparison has become stale because of at least three trends:
The first item has motivated the authors take a fresh look at the technical differences between the standards -- the gap is narrowing somewhat but not closing completely -- and to characterize the changes of the last year succinctly.
We continue to maintain an updated version [WebCGM-SVG] of the 2003 base paper on the CGM Open Web site. There is a lot of data in it, and that may be one of the reasons that our points have been been misinterpreted and misunderstood by some. Therefore, we intend in this paper to highlight the major points, without presenting all of the associated data. In this paper you will find sections about:
Please refer to data in the base paper if you have questions about details.
To address the item #2 above -- misinterpretations and misunderstandings of the 2003 results -- we have isolated a handful of the common ones. These come from such sources as public discussion lists for SVG developers [e.g., svg-developers@yahoogroups.com], SVG-advocacy Web blogs, etc. We present these points in a section:
in FAQ format.
Regarding the third item -- trends in implementations and interoperability -- our new content in this paper is at a summary level. Because of the critical importance of interoperability, maturity, and stability in many technical graphics applications, we believe that a careful and detailed look at the interoperability of implementations around both standards would be valuable. But it is beyond the scope of this present paper.
Finally, we present sections on:
The conclusions of this study depend critically on their evaluation within the context of the requirements for technical graphics [Technical Graphics Requirements] . The authors are fully aware that there are other use cases outside of technical graphics with different requirements, which may lead to different conclusions. The authors are also aware that missing functionality or features very often can be achieved by using scripts in SVG, however, scripting in files has proven to be a nightmare for the maintenance of huge technical graphics archives.
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; if scripting is used, it will be much harder.
It is beyond the scope of this paper to research the software availability on different platforms (Windows, Linux, Unix, Mac, Embedded environments etc...). This would be an interesting task for future work.
The following requirements are based on the authors' experiences in this field and do not claim to be complete. However, they are representative for a variety of industries.
W3C Requirements - The World Wide Web Consortium published a note [W3C Scalable Graphics Requirements] in 1996 detailing the requirements for scalable vector graphics used on web pages. A couple of years later two Recommendations have been released, one for WebCGM and the other one for SVG.
Graphical primitives - Technical graphics require a wide range of graphical primitives. Most of these graphics have to live for years and decades and will be revised numerous times. Thus it makes a huge difference in editing whether a circle is a circle with a radius or diameter, or just a Bezier spline or polyline.
Geometrical complexity - Technical graphics can become very complex depending on the content. The number of graphical primitives may easily exceed a couple of ten thousands. The dimensions of a drawing may be challenging as well. One of the authors recently had to deal with wiring diagrams that were over 60 inches long. At the same time there are stringent requirements for accuracy and precision.
Graphical requirements - Most technical graphics can be categorized as containing complex geometry with modest graphical requirements. A significant percentage of technical illustrations and schematics is done as black and white lineart drawings. The focus is on conveying the technical message, not on producing a nice looking image.
Precision - Technical graphics show a lot of details, thus they need to be accurate and precise. It is a usual routine to zoom far into the graphics to see the detail of interest. Precision is equally important for printing.
Text requirements - It is not exaggerated to say that probably more than 90 percent of all technical graphics use Helvetica or one of its variants as their font. This indicates that the typographical requirements are typically low, however, support for text in all languages and encodings is strongly required. A second requirement is that it must be possible to constrain text to certain areas to ensure proper data exchange with other programs. For example, a text element between two lines on a wiring diagram must not move or change its size, it needs to be restricted to a certain bounding box.
Metadata requirements - The requirements for metadata inside technical graphics files are modest but very specific. Due to the fact that these graphics appear in huge quantities (did you know that approximately 70,000 illustrations are needed to document a Boeing 747 (Source: The Boeing Company)?) nobody wants to store more metadata inside the graphic files than absolutely necessary. Typically a simple ID and a hotspot region are associated with a group of primitives, the rest is done in SGML/XML companion files or databases.
Reliability - Wherever and whenever a technical illustration or schematic drawing is used by a mechanic or engineer it is essential that he can look at the authentic information in a reliable way. Time, money, and even security issues are at stake if the information is incorrect or not understandable. Therefore it is hardly imagineable that a user himself will get control over the styling, i.e. the outer appearance of the illustration. Styling may be applied by an application under the control of the illustration's author though.
Reusability and longevity - Most technical graphics live for a long time. Ten years are normal for parts catalog illustrations, very often 20 or 30 years. Think of a Boeing 747 that has been developed and illustrated in the late 60s and early 70s. The illustrations are still in use and being modified every day. If an illustration can not be reused the work is lost.
Interoperability - Probably the biggest requirement for technical graphics is their interoperability. This means it must be possible to exchange data back and forth between different programs from different vendors without losses or changes. If graphics in the defense or aerospace industry need to be maintained for 25 years or longer, it is inevitable that a whole range of products is going to work on them. The lack of interoperability leads to significant additional cost and even to total loss of data.
The target scenarios and the positioning of WebCGM and SVG have not changed since the first version of this paper. For more detail please refer to
The 2003 study identified a number of differences related to the TG requirements for static-graphics functionality. These were presented in a table containing eight difference areas, that in turn link to detailed discussions. (This was table 2 in the 2003 study, which is presented below (Table 2 ) with 2003-2004 changes applied.)
Of this handful of static-graphics differences, the authors considered that the most important were:
The 2003 study identified a number of differences related to the TG requirements for dynamic-graphics functionality. These were presented in a table containing nine difference areas, that in turn link to detailed discussions. (This was table 1 in the 2003 study, which is presented below (Table 3 ) with 2003-2004 changes applied.)
Of this handful of dynamic-graphics differences, the authors considered that the most significant were:
The 2003 study identified a number of differences related to interoperability, a critical consideration for technical graphics applications. These were presented in a table containing nine difference areas, that in turn link to detailed discussions. This table is repeated here verbatim. (See 2004 Interoperability section below for updates about number of SVG plugins and SVG validators.)
| Interoperability topic | WebCGM Assessment | SVG Assessment |
|---|---|---|
| Resource limits and specific requirements | all aspects constrained & limited | few limits or constraints |
| Extensions, optionality, implementation dependencies | none of these are allowed | extensions unrestricted, optional features defined, some implementation dependencies allowed. |
| Predictability of text model | completely constrained and predictable | uses CSS text properties and font resolution rules |
| Styling and altering of author's intent | no styling (limited styling in planning) | full CSS styling support |
| Language flavors & strict profiles | strict profile | loose conformance, flavors developing |
| Implementation of object linking | several correct implementations (unconfirmed) | no implementations known (unconfirmed) |
| Viewer software availability & completeness | a few plugins relatively complete (unconfirmed) | two plugins, apparently incomplete (unconfirmed) |
| Generator software availability & completeness | a few specialized high-quality; many generic low-quality | some specialized as well as generic, of apparently good quality; many others (unconfirmed) |
| Test suites & validators | comprehensive breadth-first plus some detailed tests; validator available | comprehensive breadth-first plus some detailed tests; validator being built (unconfirmed) |
| Maturity & stability | very mature, changes and errata are rare | fairly young, numerous errata and clarifications/interpretations |
Table 1
The authors considered that the most important interoperability differences in 2003 were:
The authors' overall 2003 conclusions can be paraphrased as follows:
The power of SVG is impressive. Much of its power is aimed at achieving the highest graphical quality possible, and at scripting and animating the graphics. However these are largely irrelevant to the specific requirements of technical graphics. There is no doubt that both SVG and WebCGM could each store and display many particular instances of technical graphics. It takes a close look to see the gaps in the SVG coverage of the requirements.
The authors are convinced that SVG is a format with a great functionality and an even greater potential, and that its best application is in the creative-graphics sectors that it has been principally developed for. When it comes to technical graphics, the authors prefer WebCGM for its stability, maturity, and reliability.
Over the past year, the authors have become aware of a number of misinterpretations and misunderstandings of the conclusions of the 2003 paper. These have been found for example on SVG advocacy blog, mail on svg-developers list, and personal communications.
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.
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).
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 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).
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.
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.)
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.
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.
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).
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.
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.
In the year since first publication of the WebCGM-SVG analysis for technical graphics, there has been some development in both standards:
SVG 1.2 is likely to finish the Recommendation track before the end of 2004. The schedule for finishing the in-progress WebCGM changes is presently under discussion.
Below are the functionality comparison tables again, with indication of changes in the last year. Key for tables:
| Functionality | WebCGM Assessment | SVG Assessment |
|---|---|---|
| Non-scaling linewidth modes | yes | * special case of 1.2 Vector Effects |
| Engineering line types | yes | limited |
| Linestyle definition | specific inking, offset controls for tech drawing | offset control,but no vertex inking or adaptive controls |
| NURBS | no (but see detailed comments) | no |
| File Size | compact binary | compactable text |
| Embedded raster images | raster stored in CGM file, efficient compression methods | raster in external file or embedded |
| Styling | + none (but limited CSS-like under discussion) | full CSS & XSL support |
| Encoding | binary (but XML is discussed) | text (but binary is discussed) |
Table 2
| Functionality | WebCGM Assessment | SVG Assessment |
|---|---|---|
| Object linking | links to one or several objects supported using ID or name | simple links to one object supported |
| Object behaviors | explicit support for navigation to single or multiple object(s) and highlighting | limited support for highlighting and navigation |
| Out-of-line links | possible but not standardized yet | possible using event handlers |
| Multi-links | explicitly, directly supported | * via xlink extended links in 1.2 |
| Link titles | explicitly, directly supported | * supported directly in 1.2 |
| Screentip | explicitly, directly supported | * supported directly in 1.2 |
| Document Object Model (DOM) | + draft IDL definition exists now, for a very limited DOM | full XML DOM plus SVG extensions |
| Animation | none | full-functioned declarative & DOM animation |
| Event model | + proposed improvements for out-of-line linking, object selection, etc | full-functioned event model (based on DOM2 and HTML events) |
Table 3
To summarize:
(** Explanation of "read-only" -- mostly, the requirement is for a capability for external applications to discover the structure and attributes of the graphic.)
The authors have revised some of the sections referenced by the tables above to reflect the changes, and also to clarify the issue. We recommend to read these sections again, even if you have read the original paper.
In that paper, the authors also tried to point out places where workarounds using scripting have been proposed for several of the issues. This does not constitute an endorsement of scripting for that issue, however. We are not considering scripting a solution, because of its unacceptability in some major real-world technical graphics scenarios.
In the last year, the significant developments around WebCGM interoperability were:
Also of note:
In the last year, the significant developments around SVG interoperability are:
Also of note:
Note. Leaving application profiles to the application communities is the same approach as the CGM community uses (and, the ISO CGM standard contains "Rules for Profiles" to facilitate this).
In the 2003 analysis, the authors did some selective assessment of viewer and authoring products on specific technical graphics functionality. To do this properly is a large job, and (as stated earlier) beyond the scope of this paper. We intend to postpone any further observations about implementations until the resources are available for a careful and thorough assessment. The latter, for both formats, would be a valuable resource.
Both SVG and WebCGM have clearly found their way into their respective market places. SVG gave the web community a standardized way to create highly demanding vector graphics and even an entire development environment for graphics applications. WebCGM was a major step forward to help harmonize diverging CGM profiles, and to provide a standardized linking and behavior.
The outlook for both formats is different at this point. The work on the SVG specification is in full swing, and major new things may happen any time. WebCGM will by definition take a much slower and more controlled path in its evolution, based on the requirements from industry.
SVG has found a lot of early adoptors, and more and more tools appear on the market supporting SVG. The fact that there are several free viewers helped a lot to enable users to work with SVG files. SVG is making real progress in several application areas, e.g. cell phones and 3GPP, although these are unrelated to the subject area of this comparison paper, technical graphics.
A lot of work has been done on SVG 1.2 in the meantime. According to Chris Lilley, W3C Graphics Activity Lead, it is expected to become a Recommendation around the end of 2004. There are not a lot of requirements right now reaching beyond SVG 1.2, but that may change.
Proposals have been made (e.g., at SVG Open 2003) to found an SVG consortium, but scope and mission are unclear at this point. The authors believe that the participation of strong users is an excellent idea, as CGM has shown.
SVG 1.2 mentions industry specific profiles for the first time. The details of profiles remain to be done in future versions though. A well-defined profiling mechanism would constitute a milestone for TG.
After its introduction in 1999, WebCGM has found its way into a number of products (see [CGM Product Directory] ), and it is in widespread use. Most of the projects using WebCGM files are not on public web pages though, but rather on company intranets or in secured areas of the web.
The profile has not seen any change after the release of the second edition. Within CGM Open an effort has been ongoing to deal with requirements for a limited DOM and for limited, non-persistent styling at runtime. The progress on these projects is slow, however, the DOM is expected to be finalized soon.
CGM Open is working on a roadmap for CGM and WebCGM to identify the needs for future enhancements of the profile. There is also a dialog in place with the ATA Graphics Working Group to ensure alignment of WebCGM with the GREXCHANGE profile as much as possible.
Currently, the development of WebCGM is suffering from a lack of resources, which CGM Open hopes to cure soon. However, the authors do not expect a comparable effort in the development of WebCGM as can be seen with SVG.
WebCGM is based on specific industry requirements. It has not gained a lot of additional ground in the market place outside of the classical CGM community, however, it is in heavy use within a lot of industries. Due to the fact that it is rarely used on public web pages there may be the perception that WebCGM is not important or an "old" format, but this is not the case. The typically large number of illustrations per application shows that there are a lot of CGM graphics in use today. This needs to be considered when work on the standard is done, to avoid future legacy problems.
Although there is no WebCGM Working Group inside W3C (nobody ever asked for one), there is constant work being done on WebCGM and related topics inside CGM Open. The roadmap developed by CGM Open will show the plans for CGM and WebCGM shortly.
Important: To properly understand our conclusions, please keep in mind that they are based on strict requirements in the technical graphics (TG) core application area. We are not, for example, considering other application sectors, such as mobile phones, where the requirements are significantly different and where SVG is making good penetration.
Based on technical features of the standards, there is some some narrowing of the difference between SVG and WebCGM, on the specific points of requirements for technical graphics. This narrowing is due to proposed additions that have been written into the SVG 1.2 Working Draft specification, as well as a clarified understanding about the theoretical capabilities of SVG 1.1 (e.g., compressed raster functionality). There are other significant technical differences which have not yet been addressed. Some of the differences have been disputed, by those suggesting scripting and similar solutions. We believe that scripting is simply not an option for many real-world technical graphics applications.
For technical differences between the formats, the authors believe:
It is worth recalling our initial caveat here -- that we are measuring against strict TG requirements. Therefore we do not, for example, consider the unlimited scriptability and extensibility of SVG here.
For serious real-world application in many technical graphics applications, interoperability and reliability are the paramount considerations. To frame our conclusions about interoperability, it might be useful to consider a parable of sorts. In the authors' experience, many standards seem to go through a natural and similar cycle after they are written.
CGM certainly went through this cycle, and is somewhere in the later stages now. We make no claim that all of its problems are solved yet -- they aren't. We believe SVG is experiencing the cycle, and is somewhere in the earlier stages now.
Therefore, from the interoperability perspective, the authors currently still give the edge to WebCGM over SVG, because:
That said -- that we assess WebCGM as the stronger format for application in traditional core technical graphics scenarios -- it should be noted that SVG is generating interest and has potential roles in scenarios peripheral to the traditional core application areas of technical graphics. Animated training materials, for example, could only use SVG -- there are no plans now to add animation to WebCGM. Similarly, some have made suggestions worth investigating, wherein SVG might be used as a downstream presentation format, in TG scenarios where WebCGM is the authoring and archival format.
XHTML rendition created by gcapaper Web Publisher v2.1, © 2001-3 Schema Software Inc.