Up to cover page | Back to Profile | On to ECMAScript

WebCGM 2.1 — Conformance

Contents

7. Conformance

This section and its subsections are normative, unless otherwise indicated.

7.1 Conformance definitions

WebCGM 2.1 defines conformance for these classes of product:

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).

7.2 Deprecated and obsolete features

7.2.1 Obsolete features

The following features of WebCGM 1.0, 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:

7.2.2 Deprecated features

TODO: TC has started to discuss and must decide if these now are 2.1 obsolete! (In which case, 2.0-obsoleted and 2.1-obsoleted could become sub-sections of "7.2.1 Obsolete features"

The following WebCGM 1.0 features were deprecated in WebCGM 2.0, and may be removed (made obsolete) in some post-2.0 version:

For WebCGM 2.1, the following general definition of deprecation applies. 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.

HERE! Maybe a back reference to 2.0 conformance clause for the above paragraph and the below paragraph.

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 were required to support these behaviors, and WebCGM 2.1 viewers are similarly required. 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.

7.3 Optional features

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.

7.4 Extensibility

7.4.1 Extensibility by implementations

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.

7.4.2 Extensibility by profiles

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.

7.5 Normativitity

7.5.1 Normative and informative content

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.

7.5.2 Normative language and conformance requirements

The individual conformance requirements of this specification are presented in these principal ways:

7.6 Validation tools

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:

Back to top of chapter