Movatterモバイル変換
[0]ホーム
Up to cover page |Back to Profile |On to ECMAScript
WebCGM 2.1 — Conformance
This section and its subsections are normative, unless otherwiseindicated.
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-behaviorsfunctionality. Viewer conformance to the static graphics functionality can bemeasured for any kind of WebCGM viewer. Full viewer conformance to thedynamic behaviors specifications can only be measured in an environment ofHTML-based documents and Web browsers. Therefore, full dynamic conformance ofa viewer to all specifications in WebCGM 2.1 can only be measured for aWebCGM browser plugin (or equivalent architecture).
WebCGM 2.1 viewers, both static anddynamic, shall correctly handle valid WebCGM 2.1 Binary-encoded metafilesthat aregzip-compressed.WebCGM 2.1 viewers that claim to correctly handle valid WebCGM metafiles ofan earlier WebCGM version (1.0 or 2.0) according to the conformance rules ofthat earlier version, shall correctly handle such metafiles when they aregzip compressed.
The following WebCGM 1.0 features, deprecated in an earlier release ofWebCGM, were made obsolete in WebCGM 2.0, and are not part of the WebCGM 2.0standard 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 ofWebCGM, 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 handle2.1-obsoleted features; however, viewers that claim full backward-compatiblesupport of earlier WebCGM versions do have support requirements.
In the case of the three object behaviors, in WebCGM 2.0 the followingrequirement supplemented the general defined requirements for deprecatedfeatures: WebCGM 2.0 viewers were required to support these behaviors. Suchsupport shall be according to thedefined mapping onto the 2.1 setof object behaviors. Note. This specification is made because legacyoccurrences of these behaviors can originate in non-CGM content types, andcan occur independently of the versioning mechanism of WebCGM content.
The following WebCGM features are deprecated in WebCGM 2.1, and may beremoved (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 generaldefinition ofdeprecation 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 staticimplementations 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 thegiven 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 theWebCGM Proforma of Chapter 6.
- DOM
A conforming WebCGM DOM implementation must implement the interfaces ofWebCGM 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 theload 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 theAppliction Configuration Items chapter.
This sub-section is informative (non-normative.)
One design goal of WebCGM is to serve as a foundation profile for a familyof closely related technical application sectors. The aim is that thosesectors may succinctly present their profile definitions as delta documentsfrom WebCGM, as explained inCascadingProfiles. The following rules should be observed by suchprofiles.
- Metafiles
- Profiles typically define their valid metafile content to be a subset of the fullWebCGM 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 eitherprofile defined (sufficient for universal unambiguous implementation) orregistered (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 withapplication-specific metadata in foreign namespaces, following the extension rules defined in Chapter 5,XML Companion File. As forimplementation-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 theAppliction Configuration Items chapter.
The sections and subsections of this specification are labeled, after thesection heading, to specify whether they are normative or informative. If asubsection is not labeled, it has the same normativity as its parentsection.
For example, this conformance clause (Appendix A) says, right after thesection heading, "This section and its subsections are normative, unlessotherwise indicated."Section 7.4.1has no label, so it is normative, while7.4.2says "This sub-section is informative (non-normative.)"
Allexamples in this specification are informative. Allillustrations in this specification are informative. AllEBNF in thisspecification is normative, unless specifically labeled as informative. AllDTDs and DTD fragments are normative, unless specificallylabeled as informative.
The individual conformance requirements of this specification arepresented in these principal ways:
- RFC 2119 Keywords: Seesection 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 insureinteroperability through the use of validation tools against CGM instancesand certification services for applications. Once an application has beencertified through a testing service, behavior of that application ispredictable under the constraints of the profile. Validation andcertification tools and services which exist (or have existed) and can beleveraged for WebCGM are:
- Validation tools exist for metafileinstances.
- AWebCGM 1.0 test suite.
- AWebCGM 2.0 test suite.
- AWebCGM 2.1 test suite.
- Previous test suites and certification services forinterpreters 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
[8]ページ先頭