Up to cover page | Back to Profile | On to ECMAScript
WebCGM 2.1 — Conformance
This section and its subsections are normative, unless otherwise
indicated.
WebCGM 2.1 defines conformance for these classes of product:
- WebCGM 2.1 instances
- WebCGM viewers (static)
- WebCGM viewers (dynamic), including WebCGM DOM implementation
- XML Companion File (XCF) instances
- Application Configurable Items (ACI) file instances
WebCGM contains both static graphics functionality and dynamic-behaviors
functionality. Viewer conformance to the static graphics functionality can be
measured for any kind of WebCGM viewer. Full viewer conformance to the
dynamic behaviors specifications can only be measured in an environment of
HTML-based documents and Web browsers. Therefore, full dynamic conformance of
a viewer to all specifications in WebCGM 2.1 can only be measured for a
WebCGM browser plugin (or equivalent architecture).
WebCGM 2.1 viewers, both static and
dynamic, shall correctly handle valid WebCGM 2.1 Binary-encoded metafiles
that are gzip-compressed. WebCGM 2.1 viewers that claim to correctly
handle valid WebCGM metafiles of an earlier WebCGM version (1.0 or 2.0)
according to the conformance rules of that earlier version, shall correctly
handle such metafiles when they are gzip compressed.
The following WebCGM 1.0 features, deprecated in an earlier release of
WebCGM, were made obsolete in WebCGM 2.0, and are not part of the WebCGM 2.0
standard nor of this WebCGM 2.1 standard:
- multiple pictures -- a valid WebCGM 2.0 or WebCGM 2.1 instance may only
contain one CGM picture; WebCGM 1.0 allowed multiple pictures.
- symbol libraries -- this 1.0 functionality was unused and unseen in the
five years between WebCGM 1.0 and 2.0, therefore all elements associated
with Symbol Libraries were removed from WebCGM 2.0 and not part of WebCGM
2.1.
- continued Application Structures -- disallowed in WebCGM 2.0, and not
allowed in WebCGM 2.1
The following WebCGM 2.0 features, deprecated in an earlier release of
WebCGM, were made obsolete in WebCGM 2.1, and are not part of WebCGM 2.1:
- TILE compression types 0, 1, 2
- BITONAL TILE compression types 0, 1
- the 'viewport' param element (unused and unseen since publication of
WebCGM 1.0.)
- the three WebCGM 1.0
object behaviors in the IRI fragment -- highlight, view_context,
highlight_all. (These were deprecated and replaced in 2.0 by a set of
behaviors that are atomic, orthogonal and comprehensive in
combination.)
Note: viewers that only claim WebCGM 2.1 compliance need not handle
2.1-obsoleted features; however, viewers that claim full backward-compatible
support of earlier WebCGM versions do have support requirements.
In the case of the three object behaviors, in WebCGM 2.0 the following
requirement supplemented the general defined requirements for deprecated
features: WebCGM 2.0 viewers were required to support these behaviors. Such
support shall be according to the defined mapping onto the 2.1 set
of object behaviors. Note. This specification is made because legacy
occurrences of these behaviors can originate in non-CGM content types, and
can occur independently of the versioning mechanism of WebCGM content.
The following WebCGM features are deprecated in WebCGM 2.1, and may be
removed (made obsolete) in some future version:
- the 'background' param element (unused and unseen since publication of
WebCGM 1.0.)
- the WebCGM 1.0 Character Set List designation tails for UTF-8 and
UTF-16 were replaced by correct derivations in WebCGM 2.0, and the 1.0
forms are deprecated.
For WebCGM 2.1, the following general definition of
deprecation applies:
- For WebCGM content: Deprecated features must not be present in
conforming 2.1 content, but must be supported by conforming 2.1 viewers
that support conforming 2.0 content.
- For other content types: Deprecated features should not be used in new
non-CGM content (e.g., HTML content); but must must be supported by
conforming 2.1 viewers that support conforming 2.0 usage.
There are no optional features in WebCGM. Conforming static
implementations must implement all static functionality as defined herein.
Conforming dynamic implementations must implement all dynamic functionality,
including DOM and XCF functionality, as defined herein.
For WebCGM implementations, the following extensibility rules apply to the
given WebCGM components for which WebCGM defines conformance.
- Metafiles
- Metafiles are absolutely not extensible. There shall be no content in
conforming WebCGM metafile instances beyond what is defined and allowed
by the WebCGM Proforma of Chapter
6.
- DOM
A conforming WebCGM DOM implementation must implement the
interfaces of WebCGM DOM definition
(Chapter 5) exactly as described therein. Any DOM implementation,
whether profile defined or private (vendor defined), that extends,
subsets, or modifies the WebCGM DOM is not a conformant WebCGM DOM
implementation. The specification of a DOM based on or derived from the
WebCGM DOM is considered to be a new, independent DOM that would be
outside of the scope of the WebCGM specification. Such a DOM would not
be WebCGM conformant, and a WebCGM DOM implementation is not expected
to handle this DOM.
- Companion files (XCF)
- XML Companion Files (XCF) are extensible with application-specific
metadata in foreign namespaces, following the extension rules defined
in Chapter 5, XML Companion
File. Such namespace extensions shall have no graphical
effects, i.e., if the namespace extensions are stripped from a
companion file, then the graphical rendering following the load and apply of that XCF shall be
the match the rendering following the load-and-apply of the unaltered
XCF.
- Configuration files
(ACI)
- The ACI file is not extensible. There shall be no content in
conforming ACI file instances beyond what is defined and allowed by the
Appliction Configuration Items
chapter.
This sub-section is informative (non-normative.)
One design goal of WebCGM is to serve as a foundation profile for a family
of closely related technical application sectors. The aim is that those
sectors may succinctly present their profile definitions as delta documents
from WebCGM, as explained in Cascading
Profiles. The following rules should be observed by such
profiles.
- Metafiles
- Profiles typically define their valid metafile content to be a subset
of the full WebCGM Proforma
(Chapter 6). Other than subsetting values and elements, profiles should
not modify any standard WebCGM content. Profiles may extend standard
WebCGM content by using the defined CGM:1999 extension mechanisms
(ESCAPE, GDP, APPLICATION DATA), provide the constraints of CGM:1999
Rules for Profiles (clause 9) are observed. Specifically, such
extensions should be either profile defined (sufficient for
universal unambiguous implementation) or registered (in the
ISO Registry of Graphical Items). Note: Profiles should use caution
when extending valid metafile content, as it fragments implementations
and creates interoperability problems with other application
sectors.
- DOM
- Profiles based on WebCGM should not modify or add to the standardized
WebCGM DOM methods or interfaces. Neither should such profiles add
entirely new interfaces. A profile-defined DOM based on or derived from
the WebCGM DOM is considered to be a new, independent DOM. A WebCGM DOM
implementation should not be expected to interoperate with this DOM.
The recommendations of this paragraph should help to minimize the
interoperability differences amongst closely-related technical
constituencies whose profiles derive from WebCGM.
- Companion files (XCF)
- Profiles may subset WebCGM WebCGM's XML Companion File (XCF)
definition. Profiles may extend WebCGM's XCF definition with application-specific metadata in
foreign namespaces, following the extension rules defined in Chapter 5,
XML Companion File. As for
implementation-defined XCF extensions,
profile-defined XCF extensions shall be non-graphical.
- Configuration files (ACI)
- The ACI file is not extensible. There shall be no content in
conforming ACI file instances beyond what is defined and allowed by the
Appliction Configuration Items
chapter.
The sections and subsections of this specification are labeled, after the
section heading, to specify whether they are normative or informative. If a
subsection is not labeled, it has the same normativity as its parent
section.
For example, this conformance clause (Appendix A) says, right after the
section heading, "This section and its subsections are normative, unless
otherwise indicated." Section 7.4.1
has no label, so it is normative, while 7.4.2
says "This sub-section is informative (non-normative.)"
All examples in this specification are informative. All
illustrations in this specification are informative. All EBNF in this
specification is normative, unless specifically labeled as informative. All
DTDs and DTD fragments are normative, unless specifically
labeled as informative.
The individual conformance requirements of this specification are
presented in these principal ways:
- RFC 2119 Keywords: See section 1.1 about
interpretation of the RFC keywords when they occur in normative sections
of this specification. Occurrences of these words in normal lowercase
have the RFC-2119-defined normative implications.
- Descriptive language: Descriptive prose that defines a graphical or
dynamic effect to be achieved, when occurring in a normative section,
represents conformance requirements. For example: "A non-visible object
is not displayed."
- Imperative voice: Imperative voice statements that define a graphical
or dynamic effect to be achieved, when occurring in a normative section,
represents conformance requirements. For example: "If the picture
behavior value is any valid name string other than the above reserved
names, (it begins with an alphabetic character (a-zA-Z)), remove the
existing content (picture or document) from the frame whose name matches
the string and display the specified content in the specified frame."
This subsection is informative (non-normative).
One of the benefits of using any CGM profile is the ability to insure
interoperability through the use of validation tools against CGM instances
and certification services for applications. Once an application has been
certified through a testing service, behavior of that application is
predictable under the constraints of the profile. Validation and
certification tools and services which exist (or have existed) and can be
leveraged for WebCGM are:
- Validation tools exist for metafile instances.
- A WebCGM 1.0
test suite.
- A WebCGM
2.0 test suite, currently being upgraded to 2.1.
- Previous test suites and certification services for
interpreters for the closely related ATA profile -- several
viewer, printer, and interpreter products that now also support WebCGM
were certified for ATA compliance.
Back to top of chapter