Up to cover page | Back to Profile | On to ECMAScript
WebCGM 2.0 — Conformance
This section and its subsections are normative, unless otherwise
indicated.
WebCGM 2.0 defines conformance for these classes of product:
- WebCGM 2.0 instances
- WebCGM viewers (static)
- WebCGM viewers (dynamic), including WebCGM DOM implementation
- XML Companion File (XCF) 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.0 can only be measured for a
WebCGM browser plugin (or equivalent architecture).
The following features of WebCGM 1.0, deprecated in an earlier release of
WebCGM, have been made obsolete, and are not part of the WebCGM 2.0
standard:
- multiple pictures -- a valid WebCGM 2.0 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 have been removed from WebCGM 2.0.
- continued Application Structures
The following WebCGM 1.0 features are deprecated in WebCGM 2.0, and may be
removed (made obsolete) in a future version:
- TILE compression types 0, 1, 2
- BITONAL TILE compression types 0, 1
- the three WebCGM 1.0
object behaviors in the IRI fragment -- highlight, view_context,
highlight_all -- are deprecated and replaced by a set of behaviors that
are atomic, orthogonal and comprehensive in combination.
- the 'viewport' param element (unused and unseen in the five years
between WebCGM 1.0 and 2.0.)
- the WebCGM 1.0 Character Set List designation tails for UTF-8 and
UTF-16 are replaced by correct derivations in WebCGM 2.0, and the 1.0
forms are deprecated.
For WebCGM 2.0, the following general definition of
deprecation applies. Deprecated features must not be present in
conforming 2.0 content, but must be supported by conforming 2.0 viewers that
support conforming 1.0 content.
The following requirement supplements the general defined requirements for
deprecated features, for the specific case of the three deprecated object behaviors: WebCGM 2.0
viewers shall support these behaviors, and such support shall be according to
the defined mapping onto the
2.0 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.
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.
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.
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, currently being upgraded to 2.0 (first public release
pending).
- 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