OASIS CGM Open WebCGM V2.0 Errata

Computer Graphics Metafile (CGM) is an ISO standard, defined by ISO/IEC 8632:1999, for the interchange of 2D vector and mixed vector/raster graphics. WebCGM is a profile of CGM, which adds Web linking and is optimized for Web applications in technical illustration, electronic documentation, geophysical data visualization, and similar fields. First published (1.0) in 1999 and followed by a second (errata) release in 2001, WebCGM unifies potentially diverse approaches to CGM utilization in Web document applications. It therefore represents a significant interoperability agreement amongst major users and implementers of the ISO CGM standard.

WebCGM 2.0 adds a DOM (API) specification for programmatic access to WebCGM objects, and a specification of an XML Companion File (XCF) architecture, for externalization of non-graphical metadata. WebCGM 2.0, in addition, builds upon and extends the graphical and intelligent content of WebCGM 1.0, delivering functionality that was forecast for WebCGM 1.0, but was postponed in order to get the standard and its implementations to users expeditiously.

The design criteria for WebCGM aim at a balance between graphical expressive power on the one hand, and simplicity and implementability on the other. A small but powerful set of standardized metadata elements supports the functionalities of hyperlinking and document navigation, picture structuring and layering, and enabling search and query of WebCGM picture content.

This document was last revised or approved by the OASIS CGM Open WebCGM TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.

These errata are being produced jointly by OASIS and W3C. The two organizations' respective final versions of these errata, published concurrently, apply respectively to the OASIS Standard and the W3C Recommendation. They have identical content except for cover page and formatting differences as appropriate to the two organizations.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page ( at www.oasis-open.org/committees/tc_home.php?wg_abbrev=cgmo-webcgm .)

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page ( www.oasis-open.org/committees/cgmo-webcgm/ipr.php .)

The non-normative errata page for this specification is located at www.oasis-open.org/committees/cgmo-webcgm.

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

In the XCF DTD snippet for the 'grobject' element (section 4.3.5), the attribute declaration for the 'visibility' attribute is missing the "inherit" value. This mistake is not repeated for any of the other elements (layer, para, etc.) of section 4.3. The 'visibility' attribute declaration is also correct in the complete XCF DTD of section 4.4, and is correct as well in the complete external DTD file.

In T.15.4 of section 6.4, WebCGM 2.0 limits the number of elements within a CLOSED FIGURE to 1024. The limit is meant to apply to graphical primitive elements, as indicated in discussion by one of the Model Profile authors: "There is no logical reason to include attribute elements. The purpose of the limit is to make predictable the resource requirements of the viewer, and attribute elements have negligible bearing on that."

This qualification is not explicitly stated in the PPF as written (T.15.4 in section 6.4). Therefore, although it would be contrary to the rationale for the limit, it could be read as limiting the total of all kinds of elements. Whereas the ultimate solution would involve clarifying the Model Profile with a CGM:1999 defect correction, the practical companion solution is for the working profiles (WebCGM, ATA, etc) to clarify it, as it seems to have been almost universally assumed.

In the row that immediately follows the row containing "T.15.4" in section 6.4, in the WebCGM Profile column (the middle column) change

Other:Note that the 1024 element limit applies to the maximum number ofgraphical primitive elements. Eligible elements of classes other than graphical primitives that are included within the CLOSED FIGURE, e.g., primitive attribute elements, do not count against the 1024 limit.

T.26.10 in WebCGM 2.0 section 6.15 adopts for WebCGM the treatments of degenerate graphical primitives that are recommended in annex D of CGM:1999. CGM:1999 D.4.5.12 specifies that coincident start ray and end ray in ELLIPTICAL ARC CLOSE should result (among other things) in drawing of a radius. It is implicit, but not explicitly stated, that the radius is drawn along the coincident start-end rays -- this is the only location that fits the rationale behind the choice of fallbacks for such degeneracies. (Ultimately, there should be a CGM:1999 defect correction to put the explicit statement into D.4.5.12.)

Clarify in T.26.10 of WebCGM 2.0 section 6.15 that the drawn radius is along the start-end rays. In the row following the line containing "T.26.10", add to the WebCGM Profile column (the middle column) the following:

Note. For degenerate ELLIPTICAL ARC CLOSE, the radius specified in D.4.5.12 is drawn along the coincident start-end rays.

In XCF definition of Chapter 4, all element names in section 4.3, and their associated attributes, are lower case. This includes 'apsid' attribute that occurs on many of the 4.3 elements. In example 5.1b of section 5.3, camel-case is used for 'apsId'. This is incorrect XCF according to section 4.3, and must be fixed.

There are other occurrences of the camel-case 'apsId' usage in Chapter 5. In section 5.7.5 it appears as 'apsId' in a parameter name for a method, which is more or less harmless. In section 5.7.6 the attribute of the object is defined as 'apsId' (READONLY). While this might be bad practice to write it differently than in Chapter 4, in the specific context of these XCF and the DOM definitions, it will not lead to implementation problems in practice. Whereas changing to lower-case would invalidate existing DOM scripts.

It is implicit in WebCGM 2.0 section 3.4, but never stated explicitly, that the values of the attributes of the <param> element are case insensitive. See for example the various treatments of 'middle' in the text and examples. This is consistent with the Ch.6 PPF convention of case insensitivity wherever possible in non-graphical text. See, for example, the sub-strings of the METAFILE DESCRIPTION element (T.16.2 of section 6.5) and the font names in the FONT LIST element (T.16.13 of section 6.5). Comparison of WebCGM 2.0 section 3.4 with WebCGM 1.0 section 3.4 also shows additional case-insensitivity assumption.

In section 3.4, add to the end of the paragraph that immediately precedes the definition list of <param> definitions, i.e., immediately before the line "onload: <eventHandlerName(evt)>":

The names and the permissible values are case-insensitive, with the single exception of the value of the 'onload' <param> (which identifies the event handler script function that is to be invoked upon the onload event, represented below as"<eventHandlerName(evt)>".

There is a transcription error in T.20.2 of section 6.9, the LINE TYPE element. In the Model Profile column (the middle column), the "negative values" specification is applicable to [v3] and [v4] metafiles, not just [v3] metafiles. The transcription error was fixed in the Model Profile column (right-hand column) during publication of 2.0, but was overlooked in the WebCGM Profile column (middle column).

In the row after the row containing "T.20.2" in section 6.9, in the WebCGM Profile column (the middle column), change