Movatterモバイル変換

1. Introduction to WebCGM

This chapter's sections are informative, unless otherwiseindicated.

1.1 Terminology

This section is normative.

The key words words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to beinterpreted as described in[RFC2119].

1.2 Normative references

This section is normative.

ISO/IEC 8632:1999(E)

Information technology - Computer graphics - Metafile for the storage and transfer of picture description information
- Part 1: Functional description
- Part 3: Binary encoding
- Part 4: Clear text encoding

Available at the ISO page ofPublicly Available Standards. CGM:1999 was reaffirmed by ISO, without changes, at its 5-year review in 2004. The WebCGM profile is defined by reference to the ISO standard.

ISO Register

ISOInternational Register of Graphical Items, the normative repository of registered extensions to ISO CGM. Available at http://jitc.fhu.disa.mil/nitf/graph_reg/graph_reg.html. Aninformative summary of registered CGM items, including pointers into the normative register, is available at http://www.cgmopen.org/technical/registry/ .

ISO/IEC 8632-1:1999/Cor 1:2006

This corrigendum to CGM:1999 corrects an error in the specification of NURBS knots list in CGM:1999. Available at:http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=44114 .

ISO/IEC 8632-1:1999/Cor 2:2007

This corrigendum to CGM:1999 clarifies the permissibility and usage rules of Application Structures in the Text Open State of CGM:1999. Available at:http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50315 .

RFC 3986

Uniform Resource Identifiers (URI): Generic Syntax, Eds. T.Berners-Lee, R.Fielding, L.Masinter, January 2005, available at http://www.ietf.org/rfc/rfc3986.txt .

RFC 3987

Internationalized Resource Identifiers (IRIs), M.Duerst, M. Suignard, January 2005, available at http://www.ietf.org/rfc/rfc3987.txt .

RFC 1951

Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC1951, Aladdin Enterprises, May 1996. Available at:http://www.ietf.org/rfc/rfc1951.txt .

RFC 1952

Deutsch, P., "GZIP file format specification version 4.3", RFC1952, Aladdin Enterprises, May 1996, available at:http://www.ietf.org/rfc/rfc1952.txt .

ISO/IEC 10646

ISO (International Organization for Standardization).ISO/IEC 10646-1:2000. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane andISO/IEC 10646-2:2001. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 2: Supplementary Planes, as, from time to time, amended, replaced by a new edition or expanded by the addition of new parts. [Geneva]: International Organization for Standardization. (See http://www.iso.ch for the latest version.)

ISO/IEC 10646-UTF8

ISO/IEC 10646-1:1993, AM2:1996, Information technology — Universal multiple-octet coded character set (UCS) — Part 1: Architecture and Basic Multilingual Plane AMENDMENT 2: UCS Transformation Format 8 (UTF-8). Available from ISO, see http://www.iso.ch .

ITU-jpeg

Information technology – Digital compression and coding of continuous-tone still images – Requirements and guidelines. ITU-T Recommendation T.81. Available at http://www.w3.org/Graphics/JPEG/itu-t81.pdf. . (ISO/IEC 10918-1 : 1993(E))

REC-png

Portable Network Graphics (PNG) Specification (Second Edition) - Information technology - Computer Graphics and image processing - Portable Network Graphics (PNG): Functional specification. ISO/IEC 15948:2003(E).W3C Recommendation 10 November 2003, available at http://www.w3.org/TR/2003/REC-PNG-20031110 .

RFC 2119

IETFRFC 2119: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt .

XML 1.0

Extensible Markup Language (XML) 1.0 (Fifth Edition), Eds. T.Bray, J.Paoli, C.M.Sperberg-McQueen, E.Maler, F.Yergeau, November 2008, available at http://www.w3.org/TR/2008/REC-xml-20081126/.

Namespaces in XML

Namespaces in XML 1.0 (Second Edition), Eds. T.Bray, D.Hollander, A.Layman, R.Tobin, August 2006, available at http://www.w3.org/TR/2006/REC-xml-names-20060816/ .

RFC 2781

IETF (Internet Engineering Task Force).RFC 2781: UTF-16, an encoding of ISO 10646, Eds. P. Hoffman, F. Yergeau., February 2000. (Available at http://www.ietf.org/rfc/rfc2781.txt )

RFC 3629

UTF-8, a transformation format of ISO 10646, IETF RFC 3629, STD 63, Ed. F. Yergeau, November 2003. (See http://www.ietf.org/rfc/rfc3629.txt )

Unicode

The Unicode Consortium,The Unicode Standard, Version 4, ISBN 0-321-18578-1, as updated from time to time by the publication of new versions. (Seehttp://www.unicode.org/unicode/standard/versions/ for the latest version and additional information on versions of the standard and of the Unicode Character Database).

1.3 Non-normativereferences

SVG 1.1

Scalable Vector Graphics (SVG) 1.1 Specification, Eds. J.Ferraiolo, J.Fujisawa, D.Jackson, January 2003, available at http://www.w3.org/TR/SVG11/ .

DOM Level 3 Core

Document Object Model (DOM) Level 3 Core Specification, Eds. A.Le Hors, P.Le Hégaret (plus L.Wood, G.Nicol, J.Robie, M.Champion, S.Byrne), April 2004, available at http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/ .

DOM Level 3 Events

Document Object Model Level 3 Events Specification, Eds. B.Höhrmann, P.Le Hégaret, T.Pixley, April 2006, available at http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/ .

HTML 4.01

HTML 4.01 Specification, Eds. D.Raggett, A.Le Hors, I.Jacobs, December 1999, available at http://www.w3.org/TR/html401/ .

CSS 2.0

Cascading Style Sheets, level 2, CSS2 Specification, Eds, B.Bos, H.Wium Lie, C.Lilley, I.Jacobs, May 1998, available at http://www.w3.org/TR/CSS2/ .

Xpointer Framework

XPointer Framework, Eds. P.Grosso, E.Maler, J.Marsh, N.Walsh, March 2003, available at http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ .

Cascading Profiles

Definition and description of how to write a profile using WebCGM as the starting point, for closely related technical application sectors. Athttp://www.cgmopen.org/technical/cascading-profiles.html .

WebCGM 2.1 Requirements

The requirements used to define the new functionality for WebCGM 2.1. Athttp://docs.oasis-open.org/webcgm/v2.1/WebCGM_21_Requirements.html.

WebCGM 2.0 Requirements

The requirements on which the major WebCGM 2.0 release was based. Athttp://www.cgmopen.org/technical/WebCGM_20_Requirements.html .

SpecGL 1.0

The W3CQA Framework: Specification Guidelines has guided the inclusion of the normative Conformance clause, and other conformance-related details of WebCGM. Eds. K.Dubost, L.Rosenthal, D.Hazaël-Massieux, L.Henderson,August 2005, available at http://www.w3.org/TR/qaframe-spec/ .

CGM-MIME

The IANA registry item for CGM,Final version of CGM Media Type registration, Alan Francis, 1 November 1995, available at http://www.iana.org/assignments/media-types/image/cgm .

StylableCGM

Stylable CGM, D.Cruikshank & L.Henderson, a detailed study of possible relationships between WebCGM and CSS, presented at XML Europe 2003, available at http://www.cgmopen.org/technical/stylable_cgm_submitted_0324.pdf .

Unicode TR15

Unicode Standard Annex #15, Unicode Normalization Forms, Eds. M.Davis, M.Dürst, March 2008, available at http://www.unicode.org/reports/tr15/

CHARMOD-NORM

Character Model for the World Wide Web 1.0: Normalization, Eds. F.Yergeau, M.Dürst, R.Ishida, A.Phillips, M.Wolf, T.Texin, October 2005, available at http://www.w3.org/TR/charmod-norm/ .

UAAG 1.0

User Agent Accessibility Guidelines 1.0, Eds. Ian Jacobs, Jon Gunderson, Eric Hansen, 17 December 2002, a W3C Recommendation available at
http://www.w3.org/TR/2002/REC-UAAG10-20021217/ .

WCAG 1.0

Web Content Accessibility Guidelines 1.0, Eds. Wendy Chisholm, Gregg Vanderheiden, Ian Jacobs, 5 May 1999, a W3C Recommendation available at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/ .

1.4 About WebCGM

The scope of this WebCGM^TM 2.1 specification includes thesecomponents.

1. an intelligent graphics profile of the ISO Computer Graphics Metafile (CGM) standard (ISO/IEC 8632:1999), tailored to the requirements for scalable 2D vector graphics in electronic documents on the World Wide Web;
2. a WebCGM Document Object Model (DOM), which provides an application programming interface to WebCGM objects in WebCGM-supporting applications;
3. definition of a standard WebCGM XML Companion File (XCF), which allows applications to externalize some non-graphical metadata from WebCGM instances, yet maintain a tight binding of the metadata to WebCGM objects.
4. definition of an Application Configurable Items (ACI) file, to improve predictability of interpretation of font specifications, and to precisesly specify some under-specified defaults.

WebCGM is a set of specifications targeted especially at the effectiveapplication of the ISO CGM:1999 standard to representation of 2D graphicalcontent within Web documents.

CGM has been an ISO standard since 1987, and CGM has been a registered mediatype (image/cgm) for the Internet and the World Wide Web since December 1995.WebCGM 1.0,comprising the original intelligent graphics profile of ISO CGM, was firstpublished in 1999, was re-released in 2001 with error corrections, and formedthe basis for the significant extensions of theWebCGM2.0 specification.

For much more information about WebCGM, please see theWebCGM FAQ,as well as other numerous other references and reading materials, on theOASIS CGM Open Web site.

1.5 The WebCGM profile and profilerules

The WebCGM profile is a conforming profile of ISO CGM under the stipulationsof CGM:1999 Clause 9, "Profiles and conformance", and it utilizes the ProfileProforma (PPF) of CGM:1999 Annex I.1, Proforma tables, for representation ofthe element-by-element content details.

The WebCGM profile is an "intelligent graphics" profile, which means that inaddition to graphical content based on CGM Versions 1-3, the profile includesnon-graphical content based on CGM Version 4, Application Structures. Thenon-graphical content allows the definition of hierarchies of applicationobjects, as well as the association of metadata, such as link specificationsand layer definitions, with the objects.

1.6 WebCGM requirements

The originalWebCGM1.0 profile resulted from a collaboration between the CGM Open Consortiumand W3C Graphics Activity. The requirements that determined the contentselection for WebCGM 1.0 were derived from:

• the requirements articulated in the document "W3C Scalable Graphics Requirements"(http://www.w3.org/Graphics/ScalableReq);
• the specifications and requirements defined in "Use of CGM as a Scalable Graphics Format" (http://www.w3.org/TR/NOTE-cgm [cgmreq]);
• technical recommendations from the CGM Open Consortium (seehttp://www.cgmopen.org/).

The selection criteria for the WebCGM profile include:

• graphical content: it should have high expressive power; and, it should be both widely implemented, and implementable with a reasonable level of effort.
• intelligence content (structuring and metadata elements): criteria came from the above-mentioned requirements document,[cgmreq], plus additional requirements generated during the first 5 years of deployment and use of the WebCGM 1.0 standard.

The requirements of the majorWebCGM2.0 release -- a set of additions, deletions, and modifications applied tothe 1.0 profile -- were shaped by:

• additional requirements generated during 5 years of deployment of WebCGM 1.0 in industry;
• apparent non-use of certain 1.0 features;
• need for convergence with similar profiles in closely related industries.

The content of the WebCGM 2.1 profile comprises less than a dozen items thatwere arguably within the scope of WebCGM 2.0, but which arose too late in thestandardization of the latter. TheWebCGM 2.1Requirements document summarizes these requirements.

1.7 WebCGM and other profiles

The WebCGM 2.1 intelligent graphics profile, like its predecessors WebCGM2.0 and WebCGM 1.0, is a profile of the ISO CGM:1999 standard, designed foreffective application of CGM in technical Web applications. WebCGM is not aimedat or optimized for any particular technical application sector, but isintended to satisfy general requirements shared by different but closelyrelated technical Web applications.

Following five years of deployment and application of WebCGM and othertechnical profiles (such as Air Transport Association's), some divergence beganto appear. WebCGM 2.0 represented a major effort towards convergence ofintelligent graphics profiles in closely related industries. In fact, startingwith version 2.0, it is the intention of the authors and publishers of WebCGMthat it be used as a basis for the definition of industry-specific profiles.CascadingProfiles describes the use of WebCGM as a core profile from which specificindustries derive and define their technical profiles.

1.8 Editions and releases

CGM:1999 Clause 9, "Profiles and conformance", prescribes that profilesshall maintain revision control by using a standard "ProfileEd" keyword.Instances of a profile carry this edition information in their identificationsection. Prior releases of WebCGM include:

• WebCGM Profile, 21 January 1999, the first release of WebCGM ("ProfileEd:1.0").
• WebCGM 1.0 Second Release, 17 December 2001, an errata-correcting release of the previous (also "ProfileEd:1.0").
• WebCGM 2.0, a major functional upgrade of WebCGM 1.0, simultaneously published by OASIS and W3C on 30 January 2007 ("ProfileEd:2.0").

This specification is the first release of WebCGM 2.1 ("ProfileEd:2.1").There may be future releases of WebCGM 2.1, for maintenance and defectcorrection. There may be future higher editions and versions of WebCGM.

A summary of the substantive differences between WebCGM 2.1 and WebCGM 2.0may be found in the Appendix, "What's new in WebCGM 2.1".

1.9 Roadmap to thisspecification

WebCGM is written in these major sections:

• This section, containing introductory and overview material, which ismostly informative, but does contain twonormative subsections.
• AWebCGM Concepts section,informative butnot normative.
• Detailed descriptive material on theV4 content of WebCGM, including Content Model which can be used for V4 content. This section isnormative.
• The definition of a standardXML Companion File (XCF) for use with WebCGM. This section isnormative.
• The definition of theWebCGM Document Object Model (DOM). This section isnormative (including normative IDL definitions of the DOM interfaces).
• TheProfile Proforma (PPF), comprising an extensive table which addresses every element of the ISO CGM standard, per CGM:1999 Annex I. This section isnormative.
• The normativeConformance chapter describes the conformance targets and conformance details of WebCGM.
• TheECMAScript chapter give a normative description of an ECMAScript binding for WebCGM DOM.
• TheApplication Configurable Items chapter defines an XML format for defaults specification on a number of WebCGM elements, and for font substitution.
• Appendixes, including informative sections such as revision history, comparison of WebCGM 2.1 with the previous version, etc.

Note aboutCGM examples. InChapter 5, defining the WebCGM DOM, there areexamples that end with text lines, "View this example as HTML-CGM(WebCGM-DOM-enabled browsers only.)" In document formats that supportexternal links (i.e., XHTML), each of these examples links to an XHTML snippetthat invokes WebCGM instances. To view them your browser must have a WebCGMviewer plug-in, control, or appropriate equivalent technology. To obtain such aviewer, see for example the (non-exhaustive)CGM products directoryon the OASIS/CGM Open Web site.

1.10 Document sources andregistration authority

Copies of the ISO standards may be obtained from ISO:

CGM Open

http://www.cgmopen.org/

These additional World Wide Web sites have more information on CGM:

W3C WebCGM Overview

http://www.w3.org/Graphics/WebCGM/

2. WebCGM concepts

This chapter is informative (non-normative).

2.1 The structure of a WebCGM

A WebCGM is a Version 1, 2, 3, or 4 CGM as defined in ISO/IEC 8632:1999,with some restrictions. The restrictions improve the interoperability ofWebCGM, and simplify the production of WebCGM interpreter (viewer) tools.

A WebCGM 2.1 instance, as shown in Figure 1, consists of a singlePicture.

Properties which apply to the whole metafile are defined in the MetafileDescriptor. These include descriptive information about the metafile, theprecisions of numbers, as well as identifiers for fonts and such resources.Properties which apply to the elements in the body of the picture are containedin the Picture Descriptor. These include such information as picture size andscaling, specification modes for aspects such as line width, and backgroundcolor. Because WebCGM 2.1 allows only a single picture per metafile, thedistinction -- whole-metafile versus picture-specific -- may not seem useful.However, because a WebCGM 2.1 metafile must be a valid ISO CGM:1999 metafile,the ISO CGM:1999 metafile structure is observed.

The WebCGM picture contains CGM graphic elements, as well as (optionally)Application Structures. Application Structures define intelligent objectswithin the picture, which are comprised of groups of graphical primitives.These intelligent objects may contain attributes or properties. WebCGM definesseveral types of intelligent objects - "graphical object", "paragraph","layer", and "sub-paragraph" - as well as a few properties which each group mayhave.

WebCGM 2.1 also contains a purelygraphical grouping mechanism, "graphical node", which groups graphicalprimitives as an Application Structure, but disallows the attributes orproperties that associate intelligence with objects.

Figure 1. WebCGM File Structure

2.2 Picture content and usage

2.2.1 Raster and vectorcontent

CGM supports both raster and vector graphics in the same picture. WebCGMpermits the use of popular raster compression methods — ITU-T Group 4,JPEG, and the deflate (LZ77 derivative) method of PNG — for rastercontent embedded within the picture.

For information about scaling of WebCGM pictures in Web documents, seesection"WebCGM and theobject element".

2.2.2 Drawing model

This section presents an informative description of the normative drawingmodel of theISO CGM standard, aswell as registered extensions that have been incorporated into the WebCGMprofile.

Elements rendered first may be wholly or partially hidden by elementsrendered later. In theISO CGMstandard, the writing mode of primitives is "replacement mode" —content is rendered opaquely on top of previous content. To meet per-primitive(and per-pixel) transparency requirements, WebCGM includes aregistered extension for Alphatransparency, as well asregistered color modelsRGB-alpha and sRGB-alpha.

Implementations of WebCGM are expected to behave as though they implement adrawing model corresponding to the one described below. A real implementationis not required to implement the model in this way, but the result on anydevice supported by the implementation shall match that described by thismodel.

WebCGM uses a painters model of rendering. Colors are applied in successiveoperations to the output device. When an area overlaps a previously coloredarea the new color partially or completely obscures the old. When the color isnot completely opaque the result on the output device is defined by thefollowing (mathematical) rules for compositing (all color values usepremultiplied alpha):

Pr, Pg, Pb    — Primitive color valuePa            — Primitive alpha valueCr, Cg, Cb    — Canvas color value (before blending)Ca            — Canvas alpha value (before blending)Cr', Cg', Cb' — Canvas color value (after blending)Ca'           — Canvas alpha value (after blending)Ca' = 1 - (1 - Pa) * (1 - Ca)Cr' = (1 - Pa) * Cr + PrCg' = (1 - Pa) * Cg + PgCb' = (1 - Pa) * Cb + Pb

Alpha compositing is performed in the current COLOUR MODEL (seeT.16.19).

Primitives in a WebCGM document have an implicit drawing order, with thefirst primitives in the WebCGM document getting drawn first. Subsequentprimitives are drawn on top of previously drawn primitives.

Primitives which have a value for theregistered Escape 45 other thanfully opaque, have the effect of producing a temporary separate canvasinitialized to transparent black onto which the primitive is drawn. The canvasis then composited into the background, taking into account the Escape 45value. The presence of APS in the primitive list has no effect on therendering. No temporary canvas is created. It is identical to the case of noAPS.

2.2.3 Overlaying a picture

In the ISO CGM:1999 standard, a picture has an implicit or explicit opaquebackground. Graphic elements within the picture are rendered in the order theyappear in the metafile. It is a requirement of a 2D graphics format for Webdocuments that pictures may be overlaid on previous content. For this, it mustbe controllable whether the picture background is opaque or transparent (bothcases are needed), or "translucent" (partially opaque).

Conceptually, a CGM picture's background is handled as follows. When apicture's canvas is first created in the compositing model ofsection 2.2.2, it is initialized to transparent black(0,0,0,0). Before the drawing of the first foreground primitives, the canvas isthen filled per the equations in section 2.2.2 with theeffectivebackground color of the metafile.

In metafiles that use the RGB-alpha color model, the effective backgroundcolor may be directly set in the Picture Descriptor to any valid (r,g,b,a),including transparent black (0,0,0,0). In RGB metafiles, the same effects maybe achieved by including the registered Escape 45 (alpha transparency) elementin the Picture Descriptor, which is then combined with the defined RGBbackground color to achieve any valid (r,g,b,a) effective background color.

2.3 Intelligence — Objects,Layers, Hyperlinks, Metadata

2.3.1 Overview

Within a WebCGM picture, groups of graphical primitives can be defined whichstructure graphics to meet the requirements of integration into Web documents.Groups in WebCGM are realized as standard Version 4 Application Structures(APS) of ISO CGM.

To meet the requirements of intelligent graphics, four specific group typesare defined and allowed in WebCGM: 'grobject', 'layer', 'para', and 'subpara'.WebCGM allows a fifth group type, 'grnode', as a convenience for authoringtools to preserve their graphical grouping functions. The detailed normativesyntax and semantics of the group types, including viewer behavior, is definedinChapter 3 and in thePPF. Below is a brief conceptual summary.

Every group has at least one explicit property, its unique identifier (aparameter of the Begin APS element). WebCGM groups other than 'grnode' may haveseveral explicit attributes associated with them. These attributes are realizedas standard Version 4 (V4) Application Structure Attribute elements (APSAttributes) of ISO CGM.

Chapter 3 normatively defines the detailed content model for version 4elements in WebCGM using EBNF notation. See section,"WebCGM Content Model", for aninformative (non-normative), all-at-once presentation of the content modelusing XML DTD notation.

2.3.2 WebCGM defined grouptypes

WebCGM defines a set of allowable group (APS) types, to support the Webdocument operations of hyperlinking, layered pictures, and text search withingraphics. See Chapter 3 for thedetailed normative syntax andsemantics of the allowable group types. Brief conceptual descriptionsfollow (each item is linked to its Chapter 3 normative definition):

• grobject — (graphical object) the basic grouping APS for identification of objects, principally used to identify sources and destinations of hyperlinks.
• layer — an APS type that allows the division of a picture into a set of graphical layers, for use by viewers in selective presentation and "2-1/2 D" effects.
• para — (paragraph) an APS type to facilitate text search within graphics, in cases such as multi-element, multi-line text, and other cases (e.g., polygonized text) where text search might otherwise be difficult (or impossible).
• subpara — may be used to identify smaller fragments of text within APS of type 'para', enabling, for example, the marking of the larger text block (the "paragraph") for searching purposes, and the tagging of smaller fragments as hotspots.

WebCGM does allow one other group type for the convenience of authoringtools:

• grnode — may be used for simple grouping of graphical primitives, to preserve authoring tools' grouping functions; none of the facilities (properties & attributes) for attaching intelligence may be used with 'grnode'.

Note that 'grnode' was not present in WebCGM 1.0, but was added to WebCGM2.0 to allow for better hierarchical structure in WebCGM documents. The'grnode' ("graphical node") APS allows illustration authoring tools to preservein the WebCGM metafile instance the graphical groupings that are often used bysuch tools.

WebCGM does not allow private group types in WebCGM instances. Externalprivate metadata can be associated, by id or by name, with all group (APS)types other than 'grnode' within a WebCGM. A standard external mechanism isdefined in theXML Companion Filesection.

2.3.3 Usage of WebCGM objects fornavigation

Groups of types 'para', 'subpara', and 'grobject' may be used for pickingand navigation operations in hyperlinked Web documents. These three APS typesare called "objects" in WebCGM.

Objects may contain an explicit 'region' APS Attribute, which provides theboundary for picking operations. This is known as theoverlay model ofobject identification (for picking, mouseover screentip display, etc). It isuseful in cases where the picking region of an object can not be defined byexisting geometry, for example on line art drawings or raster content.

Objects which contain graphical content have an implicit property: theboundary or bounding extent of the enclosed graphical object. This extent isused for picking and navigation operations in hyperlinked Web documents, in theabsence of a 'region' attribute. Use of this implicit boundary property forpicking and navigation operations in Version 4 CGM instances is referred to astheembedded model.

Objects may also be the target of a link. Viewers will generally move theAPS into view and scale them to fit into the viewer's rectangle. The exactviewer behavior is controlled by a set ofobject behavior keywordsassociated with the link, and the presence or absence of certainAPS Attributes on the object('viewcontext', 'region', etc.)

2.3.4 WebCGM defined groupproperties

Explicit properties or attributes of WebCGM groups are encoded as APSAttribute elements. Each APS Attribute has a "type" parameter, which identifiesthe attribute. See Chapter 3 for thedetailed normative syntax andsemantics of the allowable APS Attributes. Brief conceptual descriptionsfollow (each item is linked to its Chapter 3 normative definition):

• region — defines a spatial region that can be associated with an APS for picking and navigation purposes.
• viewcontext — defines a rectangle that can be associated with an APS for establishing the initial view upon execution of a link to that APS.
• linkuri — defines a link, whose target is specified by an IRI, for hyperlinking to text content, pictures in other metafiles, or objects within the same or other metafiles. "#" fragment syntax is defined for a full addressing model down to the object level within the picture, and specifying viewer behavior upon link traversal.
• layername — the name (required) to be assigned within an APS of type 'layer'.
• layerdesc — specifies a "layer description" string within an APS of type 'layer'.
• screentip — a string to be associated with an object, to be shown in the typical Web browser "screen tip" style when cursor passes over the object.
• name — a "common name" attribute to be associated with an object, that gives a useful search handle or way of defining searchable subtypes of the object type; also allows a group of same-name objects to be a link target.
• content — an attribute of the 'para' and 'subpara' APS, that can provide a basis for applications to build text search in cases that might otherwise prove difficult (e.g., displayed text that is stroked, rasterized, fragmented, or non-natural presentation order).
• visibility — the 'visibility' attribute indicates if an object is visible (drawn) or not, and also disables its eligibility to be picked (invisible objects are ineligible for picking).
• interactivity — the 'interactivity' attribute indicates whether or not an object is eligible to be picked (i.e., may receive mouse events), and also affects a handful of other interaction-related behaviors.

WebCGM does not allow private attribute types in WebCGM instances. Externalprivate metadata, including attributes as well as elements, can be associatedby id or by name with all group (APS) types other than 'grnode' within aWebCGM. A standard external metadata binding mechanism is defined in theXML Companion File chapter .

2.3.5 Content Model

The detailed normative syntax and semantics are presented later(Chapter 3) in this specification. Thestructure and relationships of the intelligent content are illustrated in thefollowing diagrams. In the following, "picbody" is not a specific WebCGM objecttype, but rather a convenience to refer to that part of the CGM picture whichis between the Begin Picture Body element and the End Picture Element,exclusive. Boxes with heavy borders indicate elements that are decomposedfurther, and offset boxes indicate attributes associated with an element.Similarly, gdata is not an object type, but rather a catch-all reference tozero or more CGM graphical elements which WebCGM allows, and which are valid atsuch a position according to the rules of CGM. The cgmprim attribute associatedwith gdata represents an entity that associates the graphical primitives to themodel. See Figure 2.

Figure 2a. WebCGM File Structure - picbody

Figure 2b. WebCGM File Structure - layer

Figure 2c. WebCGM File Structure - grobject

Figure 2d. WebCGM File Structure - para

Figure 2e. WebCGM File Structure - subpara

Figure 2f. WebCGM File Structure - grnode

Figure 2g. WebCGM File Structure - gdata

2.3.6 Hyperlinking

WebCGM supports object-to-object hyperlinking within individual WebCGMinstances, between WebCGM instances, from WebCGM instances to other Web mediatypes, and from other media types to WebCGM instances.

In-line linking is supported, from WebCGM objects (APS of type 'grobject', 'para', and 'subpara') to WebCGM graphic files,objects, as well as to text and other media types. WebCGM fully supportslinking from other media to WebCGM files and objects.

Links from WebCGM objects are realized as 'linkuri' APS Attribute elementscontained within the definitions of the objects. The address of the link (a'linkuri' parameter) is an Internationalized Resource Identifier (IRI) [RFC 3987], and is described in thenormative 'linkuri' section andfragment syntax subsections.

Objects may contain multiple 'linkuri' APS attribute instances,for which case the associated Link Title parameter is available to help theuser select the destination. WebCGM prescribes a uniform viewer requirement tooffer destination choice to the user for such multi-destination cases.

The target of a link, either from within a WebCGM or from another media type(e.g., HTML text), may be a WebCGM instance. WebCGM defines an optional "fragment syntax" for addressingobjects within a WebCGM metafile.

The fragment syntax, in full generality, is:

<base-IRI>#<pict-part>.<obj-part>

The <pict-part> is identified by a keyword and has two pieces, thepicture locator (either the 'PictureId' string parameter of the CGM, or thepicture sequence number), and viewer behavior upon navigating to the picture.With the WebCGM restriction of one picture per metafile (since WebCGM version2.0), the <pict-part> is not useful anymore, but is maintained in thesyntax for backward compatibility with WebCGM 1.0 metafiles and WebCGM 1.0implementations.

The <obj-part> similarly is identified by a keyword and has twopieces, the Id parameter of the object (APS), and viewer behavior.

The syntax is well-defined so that in many common cases, keywords and piecescan be eliminated and defaulted. So, for example,<base-IRI>#<string> unambiguously identifies the object (APS) whoseId parameter is "<string>" in the first (only) picture of the metafilepointed to by "<base-IRI>".

See thenormative specifications ofChapter 3 for complete details and examples.

2.4 Encodings

Supported ISO CGM encodings. ISO CGM defines two encodings of the CGMfunctionality: Binary, and Clear Text. WebCGM, like other leading industryprofiles of CGM, limits the encoding to Binary for the purposes of conforminginterchange. It is the Binary encoding which is registered as a MIME type.Using available encoding converters, the Clear Text encoding can be used fordebugging, hand authoring, demonstration, etc.

GZIP compression.WebCGM data may be compressed for transmission using gzip compression. See "7.1 Conformancedefinitions" for normative specifications regarding GZIP compression.

WebCGM has no rules regarding filenames or filename extensions. It is acommon convention that normal (uncompressed) WebCGM instances use the filenameextension ".cgm", and thatgzip-compressed WebCGM files use theextension ".cgz". However, these are only conventions and care should beexercised not to break existing links when compression is introduced intoexisting environments.

2.5 Graphical content ofWebCGM

The graphical content of WebCGM is chosen to balance the requirements ofhigh expressive power, and simplicity to implement. It is a subset of the ModelProfile (MP) of the CGM standard.

The WebCGMProfile Pro-forma (PPF),later in this document, gives the complete normative graphical content details.Following is a conceptual summary.

2.5.1 Graphical primitives

The most obvious aspect of a graphics format is the collection of graphicalprimitives - those drawing elements which define the geometric and otherpresentation content of the format. CGM:1999 contains a rich selection ofvector graphics primitives, plus fully integrated state-of-the-art compressedtile raster content.

WebCGM includes most of the significant graphical drawing primitives ofCGM:1999.

• The simple generic drawing primitives - polylines and disjoint polylines, polygons, polygon sets.
• A number of specialized objects, for convenience and efficiency - rectangles, circles and ellipses, circular and elliptical arcs and pie slices. These come in both unfilled (line) and filled flavors.
• Graphical Text primitives:
  • WebCGM allows the simple Restricted Text primitive of CGM:1999 (which carries its extent box with it), as well as the Append Text element (continuation of a text string, after change of attributes such as font, color, ...)
  • WebCGM also supports text-on-path: paths other than simple straight lines can be defined (similar to Compound Line), and the text is laid out along that path.
• Closed Figure and Compound Line - these primitives allow the construction of complex paths as a concatenation of any of the other line and fill primitives. The path may either be drawn according to CGM line attributes, or filled according to any of the permissible fill attributes.
• Smooth curves, available in two flavors:
  • the basic and popular piece-wise cubic Bezier capability of the CGM:1999 Polybezier element;
  • more powerful Non-uniform B-splines (NUBS) and Non-uniform Rational B-splines (NURBS).
• Raster capabilities are available in two flavors, fully integrated with the scalable vector functionality of WebCGM:
  • the simple, uncompressed (except for run-length) Cell Array element of CGM:1999;
  • and the compressed, tiled Tile Array capability of CGM version 3. The popular Web compression formats of ITU-T Group 4, PNG, and JPEG are among the supported compression types.

In CGM:1999 but excluded from the present version of WebCGM are:

• The unrestricted TEXT element is prohibited (the results are unpredictable, so the more reliable RESTRICTED TEXT is required).
• The Hyperbolic Arc and Parabolic Arc elements of CGM:1999 are prohibited (these are seen in some advanced engineering formats, but not yet in Web practice).
• Polysymbol - the Polysymbol element allows the sizing and placement into CGM pictures of "symbols". Symbols are defined in an external Symbol Library, which itself is a CGM. (Polysymbol was in WebCGM 1.0, but removed due to non-use.)

2.5.2 Attributes andcontrols

Attribute elements and control elements determine the details of theappearance of graphical primitives.

• Line attributes of WebCGM include line dash styles, line width, line color, and the controls over appearance of line cap and line join. Dash styles can either be predefined, or can be defined precisely by the generator of the metafile.
• Fill attributes control the appearance of the interior of filled primitives. One attribute controls the overall style of the filled-area interior - solid color, hatch, bitmap-style pattern, empty, and hollow. In the case of hatch interior, the style can either be one of a handful of predefined, or can be precisely defined in the metafile. The pattern can be defined as a small "raster tile" of two or more colors.
• The related Edge attributes control the appearance of edges of filled areas, and are for the most part identical to Line attributes.
• The appearance of graphical text can be controlled by the CGM attributes of font and character set (which corresponds tocharacter encoding in the proper terminology ofCharacter Model for the World Wide Web 1.0: Fundamentals [CHARMOD], see later), text size, orientation, inter-character spacing, expansion-compression of nominal character aspect ratios - the important aspects needed for precise control in modern graphical text presentation. The orientation attribute actually gives control not just of rotation, but skewness and aspect distortion, i.e., it is equivalent to a local transformation on text elements.
• WebCGM also supports the Generalized Text Path capability (text on arbitrary, curved paths), with the style (Generalized Text Path Mode) limited to 'axis-tangential'.
• WebCGM clipping support includes:
  • rectangular regions;
  • arbitrary complex clip regions (Protection Region, similar to Closed Figure), with Protection Region Indicator restricted to 'clip'.

The following attribute and control features of CGM:1999 are excluded fromWebCGM.

• The use of the bundled attributes model of CGM Version 1 is prohibited, which eliminates all of the Version 1 bundle index elements, the ASF elements, and the bundle-table setting elements of Version 2.
• The use of the CGM Version 2 Segment functionality is prohibited, and its dozen or so associated elements may not occur in valid WebCGM metafiles.
• The Geometric Pattern fill capability is prohibited.
• Shielding functionality is excluded, i.e., Protection Region with mode (Protection Region Indicator) 'shield'.

There are some CGM Version 3 attribute and control elements for which it isdesirable to override the default value in CGM:1999, when an explicitdefinition of the value is not present in the CGM file. This would also allowdefinition of the rendering behavior of CGM Version 1 and Version 2 files,where those attribute and control elements are not allowed, as well as allowdefinition in CGM Verson 3 files where the elements are not declared.

This is accomplished in WebCGM using a standard XML DTD to encode theallowable elements and their values in an XML instance. Examples and moredetails can be found in the WebCGM chapter onApplication Configurable Items.

2.5.3 Color andtransparency

The normal behavior of CGM:1999 viewers is to render later occurringprimitives completely opaquely on top of earlier primitives. Several notions oftransparency are supported in WebCGM. Seesection2.2.2 and2.2.3 for discussion of the CGMdrawing model and transparency options.

The full range of standard CGM:1999 color models is limited in WebCGM. Thedefault RGB model is included, as well as the models: RGB-alpha; thecolorimetric RGB space of the Web, sRGB; and sRGB-alpha. The latter three areregistered in the ISO Register of Graphical Items.

2.5.4 Character encodings andfonts

Fully international text is supported in WebCGM by:

• Allowing the Unicode UTF-8 or UTF-16character encodings to be selected in the CGM's character encoding designation and selection mechanisms (CHARACTER SET LIST, CHARACTER SET INDEX, etc).
• Requiring the use of the CGM:1999 Font Properties element, in the case of fonts outside of a required core set of 13. The Font Properties element carries a handful of parameters which are descriptive of a set of font attributes which are most commonly used to classify and call out fonts.

The defaultcharacterencoding ("character set" in the now-archaic terminology of the originalCGM:1987) isISOLatin1. This default is mandated by the ISO CGM:1999standard.

A core set of 13 fonts, the same as those in the ISO CGM Model Profile (MP),are required in WebCGM implementations.

In order to facilitate font interchange, WebCGM defines a format to specifythe mapping of font names during the import process.

This mapping is accomplished in WebCGM using standard XML DTD. Examples andmore details can be found in the WebCGM chapter onApplication Configurable Items.

2.6 WebCGM XMLCompanion File (XCF)

The XML Companion File (XCF) component of WebCGM was added in the WebCGM 2.0release. The WebCGM XCF provides a standard way to externalize metadata from aWebCGM instance, while maintaining a tight binding of that metadata to objects(APSs) in the WebCGM instance.

The WebCGM XCF was designed with three main usage scenarios in mind. AWebCGM companion file:

1. can be used to bind application specific metadata (such as a part number) to a particular Application Structure in a WebCGM illustration.
2. could also be used to update metadata in a WebCGM illustration via the WebCGM DOM (see DOM sectionRelationship with XML companion file for more information).
3. could be used as a partial inventory of a WebCGM illustration by enumerating the Application Structures IDs, types and (most) attributes. (Note that it is out-of-scope of this version of WebCGM XCF to fully mirror the hierarchical structure of a CGM graphic (see "Structure overview" in the XCF chapter.)

Examples and more details may be found in theWebCGM XML Companion File (XCF)chapter, the complete normative definition of the WebCGM XCF.

The normative definition of XCF includes a base and generic DTD. The WebCGMXCF is designed to be extensible, by other profiles derived from WebCGM, aswell as applications of WebCGM. In particular, this allows industry specificmetadata to be added to the WebCGM object model. See thenormative XCF definition for details.

The XCF is a mechanism to bind external metadata to objects in WebCGMinstances. Accordingly, unlike hierarchical tree structured WebCGM instances,the structure of the XML Companion File is mostly flat. See the normativesection,Relationship with XMLcompanion file, for more details.

2.7 WebCGM DocumentObject Model (DOM)

2.7.1 Motivation

The Document Object Model (DOM) component of WebCGM was added in the WebCGM2.0 release. An interface for programmatic access to WebCGM contents andstructure, as well as facilities to manipulate a standardized WebCGM XMLCompanion File, were perhaps the strongest driving requirements for the WebCGM2.0 release. Virtually all of the WebCGM viewer and user agent implementationshad already defined and implemented a proprietary application programminginterface (API) for such functionality.

2.7.2 Scope of WebCGM DOM

Compared with detailed, complete DOM specifications such as W3C'sXML DOM Level 3, or the DOM of theSVG 1.1 Recommendation, the WebCGM DOMhas limited scope. A full DOM would support query and discovery of all objectsand entities in a target content (graphic) instance, right down to the leafnodes of the structure tree. It would also support symmetric, detailedmodification and manipulation capabilities for changing the object.

The functionality available in the WebCGM DOM is somewhat more limited. TheWebCGM DOM exposes the document graphic structure down to the ApplicationStructure (APS) level — APS's are the fundamental addressable graphicalobjects in WebCGM, and are the building blocks of the hierarchical structuretree of a WebCGM. Other capabilites available via WebCGM DOM include:

Temporary changes to the presentation style of graphical objects may be madevia DOM and XCF "Style Properties". Recognizing similar capabilities in CSS,potential relationships between WebCGM and CSS werestudied in detail prior to theaddition of DOM-accessible and XCF-accessible Style Properties to WebCGM.Ultimately, a lean and minimal WebCGM-specific model was chosen, thatnevertheless borrowed heavily from applicable CSS concepts (such asinheritance.)

Similar temporary changes to APS Attributes — which representnon-graphical metadata associated with graphical objects — are supportedby DOM and XCF access.

DOM functionality supports query and discovery of the structure of a WebCGM,enumeration of its graphical objects, extraction of associated metadata (e.g.,hyperlinking data) from documents, and provides users with standard ways to addmore interactivity to WebCGM documents than was previously possible. It alsoprovides users withstandard ways to add more interactivity to WebCGMdocuments than was previously possible.

DOM functionality also supports manipulation and application of standardWebCGM XML Companion Files, described in theprevious section.

The WebCGM DOM supports a number of usage scenarios and gives access to anumber of useful capabilities. Collectively, theWebCGM 2.0 Requirementsand theWebCGM 2.1Requirements documents give details about the in-scope andout-of-scope capabilities of WebCGM DOM.

3. WebCGM Intelligent Content

This chapter and its sections are normative, unless otherwiseindicated.

3.1 Addressing objects

3.1.1IRI fragmentspecification

3.1.1.1 Fragmentdefinition

TheIRI(Internationalized Resource Identifier) is how resources are identified on theWeb. For example, a CGM file called web.cgm might have the followingIRI:

http://example.org/web.cgm

Application structures and pictures within a WebCGM are addressed using themechanism of theIRI fragmentidentifier. These WebCGM rules are derived from and are consistent with the Webprotocols defined inIRI [RFC 3987] andURI (Uniform ResourceIdentifier) [RFC 3986].

AnIRIwhich includes anIRI fragment identifierconsists of an optional baseIRI, followed by theseparator character "#", followed by theIRI fragmentidentifier. For example, the followingIRI can be used tospecify the "wheelAssembly" object within web.cgm:

http://example.org/web.cgm#wheelAssembly

The fragment identifier is usually specific only to a particular class ofapplications. This clause defines the WebCGM fragment identifier which allowsWebCGM viewers, web browsers, scripting engines, and other applications to:

• address (point to) specific objects within WebCGM files,
• or load and apply anXML Companion File (XCF).

TheIRIfragment syntax, as adopted by WebCGM, is based on concepts described in theXML Pointer Language (seeXPointerFramework). TheIRI fragment syntax isdefined below. The formal grammar for the WebCGM fragment is given using asimple Extended Backus-Naur Form (EBNF) notation.

Note 1. Multiple pictures per WebCGM instance were allowed in WebCGM 1.0.Since 2.0, WebCGM allows only one picture per metafile. For backwardcompatibility with existing 1.0 metafiles and with viewer implementations, thefragment syntax is unchanged with regard to the picterm.

Note 2. WebCGM 1.0 described links usingURI terminology, howeverimplementations interpreted the WebCGM 1.0 language differently, and in factsome essentially supportedIRIs(Internationalized Resource Identifiers).IRIs are a moregeneralized complement to Uniform Resource Identifiers (URIs). AnIRI is a sequence ofcharacters from the Universal Character Set [Unicode40]. AURI is constructed from a muchmore restricted set of characters. AllURIs are conformantIRIs. A mapping fromIRIs toURIs is definedby theIRIspecification, and this mapping isadapted toWebCGM below (3.1.1.4).IRIs can be convertedtoURIs if the WebCGMprocessor does not supportIRIs directly. In thisspecification, the correctIRI terminology isused.

3.1.1.2 Fragment EBNF

The following notation is used:    *  — 0 or more    +  — 1 or more    ?  — 0 or 1    ;  — separates multiple fragment entries    () — grouping    |  — separates alternatives    double quotes (") surround literalswebcgmfragment ::= picterm "." objterm |             picterm |            objterm  |            picid "." objid |            objid |             xcftermpicterm ::= pictureid | pictsequencepictureid ::= "pictid("   picid   (","  behavior)? ")"picid ::= (char)+behavior ::=  "_blank" | "_self" | "_parent" | "_replace" | "_top" | targettarget ::= (char)+pictsequence ::= "pictseqno(" picseqno ("," behavior)? ")"picseqno ::= (digit)+digit ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" objterm ::= specialForm | normalFormspecialForm ::= "id(*,clearHighlight)"normalForm ::= objectid | objectnameobjectid ::= "id("   objid   ("," objbehavior)? ")"objid ::= (char)+objBehavior ::= navTerm | highlightTerm | navTerm "+" highlightTermnavTerm ::= "full" | "zoom" | "move"highlightTerm ::= "newHighlight" | "addHighlight"objectname ::= "name("   objname  ("," objbehavior)? ")"objname ::= (char)+xcfterm ::= "xcf(" xcfurl ")"xcfurl ::= (char)+

See next section for a definition of the "char" production.

3.1.1.3 Fragment CharacterRepertoire

The productions 'picid', 'target','objid', 'objname', and'xcfurl' in thefragment grammar above are represented by parameters in WebCGM content of typenon-graphical text (CGM type SF). Their character repertoire shall berestricted as follows.

1. Firstly, per the character set for type SF data. See section6.3, T.14.5.
2. Secondly, the character repertoire for all of these productions is further restricted as defined insection 2.2 of XML 1.0, fifth edition.
3. Thirdly, the repertoire for each of these productions is further restricted as follows:
   • objid - corresponds to WebCGM Begin APS 'id' parameter; further restrictions: as thename construct defined insection 2.3 of XML 1.0, fifth edition.
   • objname - corresponds to WebCGM APS attribute of type 'name'; shall not contain (leading, trailing, or embedded) any of the whitespace characters #x09, #x0a, or #x0d, and shall not contain any leading or trailing blanks (#x20); the 1-character string "*" is reserved for special meaning and is not a validobjname; no further restrictions.
   • picid - corresponds to the 'id' parameter of WebCGM BEGIN PICTURE elements; further restrictions: as objid for any picid value occurrences within a fragment, otherwise per type SF for the id parameter in the BEGIN PICTURE element itself (see further comments below).
   • target - further restrictions: asobjid, plus must begin with [a-zA-Z], similarly to"Frame Target Name" of theHTML 4.01 Specification, upon which the set of WebCGM picture behaviors is based.
   • xcfurl - must be a validIRI, according to theencoding rules below (3.1.1.4), and follow the rules specified for the first parameter of the'linkuri' Application Structure Attribute.

Note that these character repertoires allow one or more of the characters".", ",", "(", and ")". These are significant characters in the syntax of theWebCGM fragment specification. If any of these four significant characters isto appear in a valid id/name string within a fragment instance, then thefragment shall use the unabbreviated long form, which is the first of the sixoptional forms in the 'webcgmfragment' production of3.1.1.2. In particular, all components of the longform shall be included, and none of the parts marked as optional in the EBNFmay be omitted.

Note aboutpicid: The character repertoire forpicid occurrence in the fragment ("asobjid") is morerestrictive than the repertoire for the id parameter of the BEGIN PICTUREelement itself (CGM data type SF, not further restricted). Any applicationwhich intends to use thepicid field in the fragment must generatethe picture ids to the more restrictive repertoire of the fragment. (Seefurther discussion ofpicture selection keywordsin fragments, section 3.1.2.1.)

3.1.1.4 Non-URI characters inIRIs

TheURI characterrepertoire, as defined inRFC3986, is comprised of the alphabetic and numeric characters of ASCII, plusa few punctuation marks. The character repertoires defined in 3.1.1.3, andallowed inIRIs, are much richer.The method for handling this disparity is described in this section.

AnIRI inWebCGM content must be aURI reference as defined inRFC 3986, or must result in aURI reference after the3-step escaping procedure is applied as described inRFC 3987 (IRI), section 3.1("Mapping ofIRIs toURIs"), Step 2. The procedure isapplied when a WebCGM processor (viewer, or any other WebCGM-interpretingprocess) passes theURIreference to aURIresolver.

This handling allows various degrees of "URI legal" (in the sense of RFC3986-conforming) content to appear in WebCGM content, as shown in the examplesat the end of this section. In the WebCGM context, WebCGM processors canpractically determine when to apply the 3-step escaping procedure as follows:if anIRI inWebCGM content contains a character sequence that corresponds to a validURI escaping sequence,i.e., a three-character "%HH" sequence, WebCGM processors shall consider thatsequence to be aURIescaping sequence. Such a sequence may be passed directly to theURI resolver. (This is shown inthe examples.)

This does still not guarantee that aURI will result that is validaccording all applicableURI specifications. E.g., itcould result in DNS-illegal characters in the domain name, if the input WebCGMcontent was badly formed its generator. Because it is impractical for anyapplication to check that a value corresponds to a validURI, this specification followsthe lead ofRFC 3986 in thismatter and imposes no such conformance testing requirement on WebCGMapplications. Although noURI conformance testingrequirements or error handling are specified here, WebCGM processors should, ofcourse, react gracefully to bad input.

3.1.1.5 Resolving relativeIRIs forXCFs

Theabove fragment EBNF defines axcfterm production whose 'xcfurl' parameteridentifies anXML Companion File associated theWebCGM identified by theIRI. WebCGM viewersthat supportXCF must interpretthe fragment, locate and load theXCF. The 'xcfurl' parameteris itself aIRI, and it can beabsolute or relative. WebCGM viewers shall resolve a relative'xcfurl'IRI relative to theIRI of theWebCGM instance with which theresource file isa companion — i.e. relative to the WebCGM file referenced by the basepart of theIRI containing thefragment — rather than relative to the file containing theIRI reference (e.g., anHTML file).

3.1.2 Fragment parameters

The following subsections describe in detail how fragment parameters areused to specify the picture behaviors and object behaviors of links containingthe parameters. An informative summary of the rules is provided in thelast subsection of this section (3.1.2.8).

3.1.2.1 Picture selectionkeywords

Since version 2.0, WebCGM allows only one picture per metafile. Thereforethe picture selection keywords are of limited utility, However, WebCGM 1.0allowed multiple pictures per metafile. Newer WebCGM viewers might thereforeoperate in legacy 1.0 environments or "mixed" environments:

• WebCGM 2.1 & 2.0 viewers, especially when they are upgrading and replacing WebCGM 1.0 viewers, might receive external requests to link to multi-picture WebCGM 1.0 metafiles;
• WebCGM 2.1 & 2.0 metafiles might need to link to legacy WebCGM metafiles that are multi-picture;
• WebCGM 2.1 & 2.0 viewers might receive requests for non-existent pictures in metafiles of any version, and there should be fallback behavior as there was in WebCGM 1.0.

pictid - Thepictid keyword indicates that thepicture to be viewed is identified by the id of the picture, which is the idparameter in the BEGIN PICTURE element. In the syntax, this is a requiredparameter of thepicterm production, and there may be a secondassociated parameter, whose value is an optional picture behavior specification(seeEBNF). If the metafile does not contain apicture with the specified picture id value, the first (and only) picture inthe metafile is chosen.

pictseqno - Thepictseqno keyword indicates thatthe identity of the picture to be viewed is by the sequence number of thepicture in the metafile (seeEBNF). In thesyntax, this is a required parameter of thepicterm production,and there may be a second associated parameter, whose value is an optionalpicture behavior specification. The picture sequence number shall be an integergreater than 0. If the specified picture sequence value exceeds the number ofpictures in the metafile, the last picture is displayed.

3.1.2.2 Picturebehaviors

Picture behaviors describe to the viewer how to display the remote resourceof a hyperlink. Picture behaviors are based on the syntax and semantics ofFrame TargetNames defined in theHTML4.01 Specification. The "picture behaviors" concept of WebCGM isused to collectively address CGM pictures and other Web resources. "Picturebehaviors" is use to specify the name of a relevant presentation context (e.g.,an HTML or XHTML frame, iframe, or object element) into which a document is tobe opened when the link is activated

The reserved names listed below describe the various picture behaviors. Allother Picture Behavior values shall follow the naming convention of thepresentation context in question. For example, if the presentation context isan HTML frame, then the naming convention forFrame TargetNames in theHTML 4.01 Specification is followed — ifnot one of the reserved keywords, they must begin with [a-zA-Z]."

In what follows, the following conventions apply:

• "viewer" refers collectively to a browser and/or a CGM viewer (e.g., plugin). The logical result is described, not the method of achieving the result (which in general will require action by browser or viewer or both.)
• "content" refers to either source or destination of a link, and is either a picture (CGM) or another Web resource, depending upon the formulation of the particular link.

The following PictureBehavior values, except for _replace, are based onFrame TargetNames ofHTML 4.01:

_blank

The viewer shall load the designated content in a new, unnamed window.

_self

The viewer shall load the content in the same frame as the one containing the content that refers to this target.

_parent

The viewer shall load the content into the immediate FRAMESET parent of the current frame in which the current content is displayed. This value is equivalent to "_self" if the current frame has no parent.

_replace

When _replace occurs on a CGM-to-CGM link, a WebCGM viewer shall replace the current CGM picture by the designated CGM picture in the same rectangular area in the same frame as the picture which refers to this target. If the ending resource (CGM) is the same as the linking resource, the viewer shall not reload the resource. This is the default behavior for such links..

_top

The viewer shall load the content into the full, original window (thus canceling all other frames). This value is equivalent to _self if the current frame has no parent.

If the picture behavior value is the name of a relevant presentation context(e.g., an HTML or XHTML frame, iframe, or object element), the remote resourceshall be displayed in the specified presentation context. If the presentationcontext already exists, it is re-used, replacing the existing content. If itdoes not exist, the viewer shall load the designated content (picture ordocument) in a new window with the specified name. Note that frame-target mustbe an XML Name [XML10].

WebCGM objects are often embedded in a parent language. In such a situation,link activation behaviors (picture behaviors) are defined by the parentobject's relevant language. For example, if the parent language were HTML, thenthe link activation behavior would be defined by theHTML 4.01Specification [HTML401].

<a href="someCGM.cgm" ... />

<a href="someCGM.cgm#picseqno(1,_blank)" ... />

Figures 3 and 4 below give examples of _self and _replace.

Figure 3. Example of _self

Figure 4. Example of _replace

3.1.2.3 Object selectionkeywords

id - the id of the APS of type 'grobject', 'para' or 'subpara'to be selected. The id parameter in the BEGIN APS element. If no match is foundin the picture, no object is selected.

name - the value of the 'name' attribute in an object(grobject, para, or subpara APS). This is an alternate way to address objects.All objects in the picture with matching 'name' attributes are selected. If nomatch is found in the picture, no object is selected.

In addition to these two object selection keywords, WebCGM defines onespecial form object behavior that allows a wild-cardobject selection keyword,"*". The wild-card keyword shall be usedonly in this special form.

3.1.2.4 Objectbehaviors

Object behaviors describe how to present the view of object(s) that is (are)the targeted by a hyperlink containing aIRI fragment thatselects a particular object or group of objects as the target.

3.1.2.4.1 Enumeration ofbehaviors

WebCGM contains twelve distinct object behaviors, eleven of which aregenerated by thefragment EBNF, and one of whichis defined in the EBNF as aspecial-form object behaviorfragment:

id(*,clearHighlight)

The default object behavior iszoom+newHighlight.

The next subsection defines the target rectangle of the navigationbehaviors, depending on whether a single or multiple objects are selected bytheobject selection keyword. The highlightbehaviors apply to all objects selected according to theobject selection keyword.

The object behaviors are built from a set three "atomic" navigation keywordsand a set of two "atomic" highlight keywords,defined below. The navigation keywords have nohighlighting side effects and the highlighting keywords have no navigation sideeffects — the navigation and highlighting keyword sets are orthogonal.

The special-form behavior,id(*,clearHighlight), clearshighlighting of any and all highlighted objects in the picture, withoutaffecting the navigation state of the picture.

Note that object behaviors are "cumulative". As described in the "Picture behaviors" section, if a link points to thesame CGM file that is currently viewed — e.g., a CGM-to-CGM link withinthe same file, with_replace picture behavior — then thepicture is not reloaded, and any new object behaviors are applied starting fromthe current viewing state of the picture.

The following table enumerates the object behaviors available in WebCGM. TheNavigation column indicates whether the viewer performs any navigationfor the behavior, for theselected object(s).Highlighting indicates whether the viewer adjusts the highlighting oftheselected object(s) in some way ("X") ornot.

WebCGM 1.0 defined threeobject behaviors thatWebCGM 2.0deprecated — view_context, highlight, and highlight_all. WebCGM 2.1viewers shall support these three object behaviors, and shall do so by mappingthem to WebCGM 2.1 behaviors as follows:

• view_context maps to zoom+newHighlight
• highlight maps to full+newHighlight
• highlight_all maps to full+newHighlight

3.1.2.4.2 Definition oftarget rectangle

If navigation to an object or group of objects is indicated, a targetrectangle must be calculated as follows:

• If the object APS contains a‘viewcontext’ APS Attribute, the target rectangle is described by the ‘viewcontext’ APS Attribute.
• If the object APS does not contain a ‘viewcontext’ attribute, but contains a ‘region’ attribute, the target rectangle is the rectangle enclosing the region defined by the ‘region’ APS attribute.
• If the object APS contains neither a ‘viewcontext’ nor a ‘region’ attribute, the target rectangle is the bounding box of the graphical primitives of the object.
• For multipleselected objects the target rectangle is the bounding box of the target rectangles of the individual objects, which are computed according to the preceding 3 bullets.

3.1.2.4.3 Definitionof behaviors

full

The viewer shall present a full picture view of the appropriate picture.

zoom

The viewer shall fit thetarget rectangle of theselected object(s) into the viewer’s rectangle and center it.

move

The viewer shall move (pan) the illustration such that thetarget rectangle is centered inside the viewer’s rectangle. If this would cause the VDC Extent boundary to move to the interior of the viewer's rectangle, it is implementation dependent whether or not the viewer performs that part of the centering operation. If the target rectangle is too large, the viewer shall fit the target rectangle into the viewer’s rectangle and center it.

newHighlight

Highlight theselected object(s), first removing any highlighting that may exist on objects in the picture.

addHighlight

Highlight theselected object(s), leaving highlighted any objects in the picture that may be already highlighted.

clearHighlight

See the definition of thespecial-form object behavior fragment in theenumeration of behaviors.

See the'visibility' APS Attribute fordiscussion of its effect on execution of Object Behaviors.

3.1.2.5 Zoom and pan

In addition to being able to meet the zooming and panning requirementsimposed by the above object behavior specifications, and those zooming andpanning requirements imposed by support of theobject element's parameters, viewers whichoperate in an interaction-capable environment shall have zoom and pan controlsavailable to the user. The exact methods and user interface styles for zoom andpan selection and manipulation are viewer dependent.

3.1.2.6 XML CompanionFile

Thefragment syntax can be used to load andapply anXML Companion File (XCF) together withthe WebCGM file. An interpreter that supports WebCGM DOM shall load the WebCGMfile first. Then it shall load and apply the XML Companion File specified bytheIRI (resolving a relativeIRI if necessary).Finally it shall apply theXCFbefore the first display of the CGM.

Interpreters that do not support the WebCGM DOM may ignore this fragmenttype.

3.1.2.7 Summary ofbehaviors

The following isinformative summary and is intended to providereferences to wherethe normative picture and object behaviors aredefined.

• For links that contain anIRI with anIRI fragment and have a CGM object as the remote resource, object behaviors are specified as described in section3.1.2.4.
• For link activation within a parent object (e.g., HTML) the behavior is defined by the parent object's relevant language specification (ex: HTML 'target' attribute of the<a> element) (see3.1.2.2). Any picture behavior in anIRI fragment will be ignored by viewers (see3.1.2.2).
• For links originating from a CGM resource, the picture behavior is to be expressed using the third parameter of thelinkuri Application Structure Attribute (see3.2.2.3). Note that encoding the picture behavior in the first parameter of thelinkuri Application Structure Attribute is discouraged when targeting a CGM resource (see3.2.2.3, "discouraged").
• ForDOM script to CGM links thesrc attribute of theWebCGMMetafile interface specifies theIRI of the image. Specifying behavior as part of theIRI is prohibited (see5.7.3 'src').

3.1.3 Examples

This subsection and its subsections are informative(non-normative).

3.1.3.1 Preliminaries

The WebCGM fragment in its most verbose form provides the means to addressobjects between metafiles, and tells the viewer what to do to execute the link.The default viewer behavior defines what the browser shall do if the WebCGMfragment does not explicitly define the viewer behavior.

The following examples illustrate some of the ways the WebCGM fragment canbe used. The examples describe how one might address a set of CGM filesrelating to various views of an engine which are stored on the example.org website (http://example.org/webcgm/). The CGM files contain various viewsof an engine assembly - the top view, the front view, the right view, the leftview, and the isometric view. The CGM files are identified as follows:

Metafile 1: "engine_top.cgm"

Metafile 2: "engine_front.cgm"

Metafile 3:"engine_right.cgm"

Metafile 4:"engine_left.cgm"

Metafile 5: "engine_iso.cgm"

Each metafile contains one picture, with picture id identical to themetafile name (without the ".cgm"), and with several identifiable objects— the oil pump, the cylinder head, the fan, the radiator, or thedistributor. Not all objects are shown in all views.

The objects contained in each metafile are as follows:

Metafile 1:

Oil pump: id='oil-pump-t' name='lube-system'

Cylinder head: id='cyl-hd-t' name='engine'

Fan: id='fan-t' name='cooling'

Radiator: id='rad-t' name='cooling'

Distributor: id='dist-t' name='ignition'

Metafile 2:

Oil pump: id='oil-pump-f' name='lube-system'

Cylinder head: id='cyl-hd-f' name='engine'

Fan: id='fan-f' name='cooling'

Radiator: id='rad-f' name='cooling'

Distributor: id='dist-f' name='ignition'

Metafile 3:

Oil pump: id='oil-pump-r' name='lube-system'

Cylinder head: id='cyl-hd-r' name='engine'

Fan: id='fan-r' name='cooling'

Radiator: id='rad-r' name='cooling'

Metafile 4:

Cylinder head: id='cyl-hd-l' name='engine'

Fan: id='fan-l' name='cooling'

Radiator: id='rad-l' name='cooling'

Distributor: id='dist-l' name='ignition'

Metafile 5:

Oil pump: id='oil-pump-i' name='lube'

Cylinder head: id='cyl-hd-i' name='engine'

Fan: id='fan-i' name='cooling'

Radiator: id='rad-i' name='cooling'

Distributor: id='dist-i' name='ignition'

3.1.3.2 Example 1

1st param:http://example.org/webcgm/engine_top.cgm#pictseqno(1).id(cyl-hd-t,full+newHighlight)
3rd param:_blank

When used as the value of the 'linkuri' APS Attribute (1^st and3^rd parameters) in an object in a CGM file, this example retrievesengine_top.cgm CGM file from the example.org web site and displays the first(only) picture in a new window, highlighting the object with an id of"cyl-hd-t" in a full-picture view. The existing display window remainsunchanged. The above expressions represent the preferred form (see3.2.2.3) when the link is contained within CGMcontent. The following form is legal, but discouraged (may be removed fromfuture version of WebCGM):

http://example.org/webcgm/engine_top.cgm#pictseqno(1,_blank).id(cyl-hd-t,full+newHighlight)

3.1.3.3 Example 2

http://example.org/webcgm/engine_top.cgm#pictid(engine_top).id(oil-pump-t,full+newHighlight)

When used as theIRI in an OBJECTelement in HTML, this example displays the CGM inside a rectangle defined bythe width and height parameters of the OBJECT tag, displaying the whole picturewith the pump highlighted.

3.1.3.4 Example 3

IRI:http://example.org/webcgm/engine_iso.cgm#id(dist-i,zoom+newHighlight)
HTML 'target' attribute:topframe

When used as the value of theIRI to target an objectin a CGM file from an HTML file, thisIRI (plus HTMLattribute) retrieves the engine_iso.cgm CGM file from the example.org web siteand displays the picture in the metafile in the frame named "topframe",highlighting the object with an id of "dist-i". If present, the 'viewcontext'APS Attribute for the object "dist-i" is used to determine the rectangularportion of the picture to display in the frame, else the fallback computationof atarget rectangle used.

3.1.3.5 Example 4

1^stparam:http://example.org/engine_front.cgm
3^rdparam:topframe

When used as the value of the 'linkuri' to target an object in a CGM filefrom another CGM file, this linkuri (1^st and 3^rdparameters) retrieves the engine_front.cgm CGM file from the example.org website and displays the picture in the metafile in the frame named "topframe",with a full-picture view. (See example 1, about alternate but discouragedforms.)

3.1.3.6 Example 5

http://example.org/webcgm/engine_top.cgm#name(cooling)

This example retrieves the engine_top.cgm CGM file from the example.org website and displays the picture in the metafile. The view zooms to thetarget rectangle, which contains all objects with'name' APS Attribute with value "cooling", and each such object ishighlighted.

3.1.3.7 Example 6

http://example.org/webcgm/engine_top.cgm#fan-t

This example retrieves the engine_top.cgm CGM file from the example.org website and displays the first (only) picture in the metafile. The view is zoomedto thecomputed target rectangle of the objectwith id "fan-t", and it is highlighted.

3.1.3.8 Example 7

#id(oil-pump-t, addHighlight)

This example will leave unchanged the current zoom and pan factors in thecurrently displayed picture, and will highlight theoil-pump-tobject. Any existing highlighting of other objects in the picture ispreserved.

3.2 Application Structure and APSAttribute descriptions

3.2.1 ApplicationStructures

WebCGM defines these Application Structure (APS) types: layer, grobject,para, subpara, and grnode. This document uses the term "object" to refer to anAPS of type 'grobject', 'para', and 'subpara'.

Although the picture body of a WebCGM picture is not itself an APS, thecontent rules of the picture body (picbody) are defined by thispiece of EBNF (see thefragment syntax fordefinition of notation):

picbody ::= layer+ |             (grobject | para | grnode | gdata)*

I.e., a picture body contains either one or more layers, or else it containsa collection of eligible APSs ('grobject', 'para', 'grnode') and graphical data('gdata'). The content rules of these APSs are defined in thefollowing sections.

CGM:1999 requires that the Begin APS element of every Application Structurehave a unique identifier parameter. The character repertoire of the APS idparameter in WebCGM content is identical to the repertoire defined for theobjid fragment production inSection3.1.1.3.

3.2.1.1 Grobject

Description. The Application Structure (APS) of type 'grobject' is used togroup graphical primitives in a picture together and assign certain attributesto the group. The object is geometrically identified either by the set ofprimitives enclosed between the BEGIN APS BODY and END APS elements (if any),or by the spatial region associated with the 'region' APS Attribute (ifpresent). APSs of type 'grobject' may contain any CGM graphical content allowedby this profile.

Definition: Theinteractive region of an object is theeffective geometric region for the purposes of all interactive cursor and mouseoperations, such as picking and mouseover. By default, thedrawn graphicalprimitives of the object define the interactive region. For filled-areaprimitives this includes: the edge, if edge visibility is 'on'; the interior,if the interior style is other than 'empty' or 'hollow'; and, the boundary, forinterior style 'hollow'. For all graphical primitive types,drawn graphicalprimitives exclude any that are fully transparent (so a fully transparentobject is equivalent to an empty object, for purposes of interactive regiondefinition). If the object contains a'region' APSAttribute, then that region area is the interactive region.

Content Model. Except when occurring in Text Open State (see 3.2.1.7), the content of an APS oftype 'grobject' is (seefragment syntax fordefinition of EBNF notation)::

• grobject ::= (grobject | para | grnode | gdata)*
• grobject APS may also contain optional APS attributes of type: region, viewcontext, linkuri, screentip, name, visibility, interactivity.

Viewer Behavior. The selection ("pick") of a 'grobject' APS, as well asother objects (APSs) that may be the target of a "pick" event, follow the rulesofWebCGM DOM events. Thoserules determine all aspects of the event processing, including the selection ofthe proper target object when there are multiple eligible candidates, and theselection of the proper handler to process the event. Viewers shall give visualfeedback to the user that a successful pick has occurred, and an indication ofthe particular object (or region) which has been picked. The exact method offeedback is viewer dependent.

If an APS is the target of a link, either from within the picture or fromcontent external to the picture, then the behavior of the viewer shall be asdefined in the section"Object behaviors".

The CGM:1999 standard allows the definition of an APS to be continued inpieces which are disjoint in the file. If an APS occurs which has the samevalue of the 'id' parameter as an earlier APS occurrence, then that isconstrued as a continuation of the definition of that object. Since version2.0, continued APS constructs are prohibited in WebCGM metafile instances.

3.2.1.2 Layer

Description. The 'layer' APS declares that the graphical content within thisAPS and any valid nested APS ('grobject', 'para', and 'grnode', but not'layer') belongs to the layer identified by the contained 'layername' APSattribute.

Content Model. The content of an APS of type 'layer' is (seefragment syntax for definition of EBNF notation):

• layer ::= (grobject | para | grnode | gdata)*
• exactly one APS attribute of type: layername
• layer APS may also contain optional APS attributes of type: layerdesc, visibility, interactivity.

Viewer Behavior. Viewers shall provide functionality to inform users of thepresence of layers, their names and descriptions. Viewers shall providefunctionality to selectively turn on and off the visibility of layers. Viewersmay, but are not required to, provide additional functionality for the viewmanipulation and browsing of layers.

3.2.1.3 Para

Description. The application structure (APS) of type 'para' may be used toidentify text ("paragraphs"). 'Para' together with 'content' can potentially enable applications tobuild text search functionality, especially in cases where the underlyinggraphical data does not comprise graphical text in a searchable form (e.g., thetext has been rasterized, polygonized, or visually-single strings arefragmented into multiple smaller text elements). Except when occurring in TextOpen State, 'para' APSs may contain any CGM graphical content allowed by thisprofile.

Content Model. Except when occurring in Text Open State (see 3.2.1.7), the content of an APS oftype 'para' is (seefragment syntax fordefinition of EBNF notation):

• para ::= (subpara | gdata)*
• para APS may also contain optional APS attributes of type: region, viewcontext, linkuri, screentip, name, content, visibility, interactivity.

Viewer Behavior. With respect to object selection and link navigation, theviewer behavior of 'para' is identical to that of 'grobject' (3.2.1.1).

This version of WebCGM does not standardize text search functionality, butprovides facilities with which applications can build such functionality. It isanticipated that a future version will define standard search functionality.

3.2.1.4 Subpara

Description. The application structure (APS) of type 'subpara', may be usedto identify smaller fragments of text within APS of type 'para'. This enables,for example, the identification of the larger text block (the "paragraph") forsearching purposes, and the tagging of smaller fragments as hotspots. Exceptwhen occurring in Text Open State (see3.2.1.7), 'subpara' APSs may contain any CGM graphical content allowed bythis profile. 'Subpara' APS may not contain any nested APS.The APS attributecontent rules of sub-para matches those of 'para'.

Content Model. Except when occurring in Text Open State (see 3.2.1.7), the content of an APS oftype 'subpara' is (seefragment syntax fordefinition of EBNF notation):

• subpara ::= (gdata)*
• subpara APS may also contain optional APS attributes of type: region, viewcontext, linkuri, screentip, name, content, visibility, interactivity.

Viewer Behavior. See3.2.1.3, 'para'.

3.2.1.5 Grnode

Description. The application structure (APS) of type 'grnode' is meant togroup basic graphical primitives only. For this reason, 'grnode' must containthe APS 'id' parameter required by CGM:1999 for all APS, but a 'grnode' cannotcontain any APS attribute elements. The content of a 'grnode' is, however, notlimited to graphical primitives. The allowed APS content of a 'grnode' is thesame as for the'grobject' ApplicationStructure.

Even if 'visibility' and 'interactivity' are not allowed on the APS, the'grnode' supports inheritance (i.e., it is possible to make a 'grnode' visibleor non-visible by inserting it within an object which support the 'visibility'attribute).

Content Model. The permissible content of an APS of type 'grnode' is:

• grnode ::= (grobject | para | grnode | gdata)*

Viewer Behavior. Unlike other application structures, 'grnode' is notinteractive; i.e., it does not receive mouse events. If a mouse event istriggered on the geometry of a 'grnode', an ancestor node of type 'grobject'may respond to the event. Therefore, the content of a 'grnode' couldeffectively appear to be interactive, for example, if the 'grnode' were adirect child of a 'grobject'. See theEvent interface for moreinformation regarding mouse events. APS of type 'grnode' also do not supportmost DOM functionality such as Style Properties, object-extent inquiry, etc.See the appropriate sections of theDOM chapterfor details.

3.2.1.6 About general metadataelements

Description. This version and level of WebCGM do not allow additional APSelements to occur, other than 'grobject', 'layer', 'para', 'subpara', and'grnode'. Private metadata may be associated with WebCGM objects by keeping themetadata outside of the CGM, and associating it with objects within the CGM. Ameans for binding external private metadata to WebCGM instances is defined inthe sectionXML Companion File (XCF).

3.2.1.7APS in Text Open State

Therules ofCGM:1999 (corrected) allow an APS to occur in Text Open State, i.e., aftera 'notfinal' RESTRICTED TEXT (RT) element but before the terminating 'final'APPEND TEXT (AT) element. This allows, for example, a substring comprising oneof the interior APPEND TEXT elements in a RT-AT-AT-...-AT sequence to becontained within an APS. Thus, for example, the APPEND TEXT element (substring)could be the target of a link, or could be the source of a link (a"hotspot").

Such an APS is referred to as asubstring APS.

WebCGM 2.1 restricts the APS types of such substring APS to:'grobject', 'para',and 'subpara'. For APS of these types that arenot substring APS, the content rules are as quoted in sections3.2.1.1,3.2.1.3, and3.2.1.4 respectively. If an APS of one of thesetypes is a substring APS, then its content is restricted as follows by therules of CGM:1999 (corrected): only the APPEND TEXT element and those textattributes normally allowable in Text Open State (under CGM:1999 rules).

The allowable APS Attributes for 'grobject', 'para', and 'subpara' are asdesignated in3.2.1.1,3.2.1.3, and3.2.1.4respectively, regardless of whether or not they are substring APS.

TheWebCGM DOM (Chapter 5) allows theapplication of geometric transforms to APS of all types except 'grnode'.Therefore, a geometric transform could potentially be targetted at an APS('grobject', 'para', or 'subpara') that contains a substring APS. In this case,the layout and rendering rules of CGM:1999 for Restricted Text and Append Text(seeISO/IEC 8632:1999, section6.7.3) shall have precedence. Any attempt to set a geometric transform on asubstring APS shall have no effect.

3.2.2 Application StructureAttributes

3.2.2.1 Region

Initial value: none
Applies to: 'grobject', 'para', 'subpara'
Inherited: no

Description. The 'region' APS Attribute provides an optional spatial region,associated with a graphical object, which assumes precedence for mouse eventoperations directed at the object, such as picking, mouseover, etc. This APSAttribute, if present, defines theinteractiveregion of an object; else, the interactive region is defined by thegeometry of the object.

Simple regions of type rectangle, ellipse, polygon, and polybezier can bedefined. Complex regions which comprise a collection of simple regions can bebuilt, allowing definition of disjoint subregions, regions with holes, etc.Their semantics (subregions, and interior/exterior definition) are identical tothose of the CGM element CLOSED FIGURE. At most one 'region' attribute may bepresent within a single APS.

Parameters. The data record is an SDR of one or more member pairs (i.e., 2*mmembers, m>=1). Each member-pair defines a simple region: the first memberis of data type Index, whose valid values are:

1. rectangle
2. ellipse
3. polygon
4. continuous polybezier

The second member is type VDC and contains:

• for rectangle: 4 VDC defining two corner points;
• for ellipse: 6 VDC defining respectively the center, and two CDP endpoints;
• for polygon: 2n VDC defining polygon vertex points
• for polybezier: 2*(3n+1) VDC values, representing 3n+1 points, defining n contiguous cubic bezier segments;

For polygon and polybezier regions, closure is implicit (if the last givenpoint does not match the first, then the viewer closes the region with astraight line segment from the last to the first).

In the case that there are multiple simple regions, m>1, then theindividual simple regions each correspond to a REGION in the sense of the CGMCLOSED FIGURE element.

Viewer Behavior. See3.2.1.1.

3.2.2.2 Viewcontext

Initial value: none
Applies to: 'grobject', 'para', 'subpara'
Inherited: no

Description. The 'viewcontext' APS Attribute provides a specification toviewers of the initial view of an object, when the viewer has been directed tonavigate to the graphical object which contains this attribute. A 'viewcontext'APS Attribute may be contained within an otherwise empty APS, in which case theAPS provides only a viewport specification. At most one 'viewcontext' attributemay be present within a single APS.

Parameters. The data record is an SDR of 1 member of type VDC defining twocorner points of a rectangle.

Viewer Behavior. See3.2.1.1.

3.2.2.3 Linkuri

Initial value: none
Applies to: 'grobject', 'para', 'subpara'
Inherited: no

Description. The 'linkuri' APS Attribute defines aIRI, to be associatedwith the object containing this attribute. When the object is selected by agraphical pick operation, and theWebCGM event model determinesthat hyperlink processing shall handle the event, then the viewer shall takenecessary action to navigate the link. Multiple 'linkuri' attributes may becontained within a single APS. If the object contains more than one 'linkuri'attribute, the user shall be given a choice of whichIRI to navigate.

Parameters. The data record is an SDR of one member, containing threestrings (type SF, String Fixed). The first string is the link destination, aIRI, thesecond string (possibly null) is a Link Title parameter, and the third string(possibly null) is the Behavior parameter. Note that a null string is azero-length string, and is not the same as an omitted parameter. The parametermust not be omitted.

The destination of a link is specified by a Internationalized ResourceIdentifier, orIRI. Seesection 3.1.1.4 for further discussion of thisparameter. This specification does not constrain the syntax or semantics of aIRI in a'linkuri' that identifies a resource that is not a CGM file (for example, anHTML or XML document).

TheBehavior string defines picture behavior associated with the link. Thevalues and meanings are as defined in3.1.2.2. Incases that the destination is not CGM media type, the 3^rd parameter,Behavior, shall be used if picture behavior is to be specified for the link(there is no other option). The Behavior string may also be used for links toCGM media types, and is the preferred method.

In thecase that theIRI points to CGM mediatype, the picture behavior may be encoded within the optional fragmentidentifier in conjunction with theIRI structure, persection3.1.1, "IRI fragmentspecification". This form is discouraged, and may be removed in a futureedition of this profile. For specifying picture behavior, particular WebCGM'linkuri' instances shall use either the Behavior string (preferred), or thepicture behavior specification embedded in the fragment (discouraged), but notboth.

3.2.2.4 Layername

Initial value: none
Applies to: 'layer'
Inherited: no

Description. The 'layername' APS Attribute declares that the graphicsassociated with the 'layer' APS containing this attribute belong to theidentified layer. The 'layername' is not required to be unique. If more thanone 'layer' APS contains the same 'layername', then the occurrences followingthe first occurrence shall be construed as continuing the definition of thenamed layer. Exactly one 'layername' attribute must be present within each'layer' APS.

Parameters. The data record is an SDR of one member, containing one string(type SF, String Fixed) - the Layer Name (identifier). The string can be null(zero-length). If the Layer Name is null, then the graphics of this objectbelong to the null layer.

Viewer Behavior. See3.2.1.2.

3.2.2.5 Layerdesc

Initial value: none
Applies to: 'layer'
Inherited: no

Description. The 'layerdesc' APS Attribute provides optional descriptivetext which is associated with the 'layer' APS in which it occurs. This may beused by viewers to facilitate required and optional layer manipulationfunctions, as described in 3.2.1.2. At most one 'layerdesc' attribute may becontained within a single 'layer' APS.

Parameters. The data record is an SDR of one member, containing one string(type SF, String Fixed).

Viewer Behavior. See3.2.1.2.

3.2.2.6 Screentip

Initial value: none
Applies to: 'grobject', 'para', 'subpara'
Inherited: no

Description. The 'screentip' APS Attribute provides an optional string, tobe associated with a graphical object, which viewers can display when thegraphical cursor passes over theinteractiveregion of the graphical object. Whether or not the screentip displayactually occurs depends on how theWebCGM event model determinesthat mouse-over events should be handled. This APS Attribute may occur withinany graphical object of WebCGM, specifically, within any APS of type'grobject', 'para', and 'subpara', and there shall be at most one occurrencewithin any particular APS.

Parameters. The data record is an SDR of one member, containing one string(type SF, String Fixed).

Viewer Behavior. Viewers shall be capable of displaying the screen tip, ifone is defined for a graphical object, visible to the user when the cursorpasses over the graphical object, in the common style of Web browsers.

3.2.2.7 Name

Initial value: none
Applies to: 'grobject', 'para', 'subpara'
Inherited: no

Description. The 'name' APS Attribute provides an optional string, thatdefines a "common name" associated with an object. Unlike the APS 'id'parameter, the 'name' APS attribute need not be unique within a metafile.Multiple 'name' attributes may be contained within a single APS.

Parameters. The data record is an SDR of one member, containing one string(type SF, String Fixed). The character repertoire of the name APS attribute inWebCGM content is identical to the repertoire defined for theobjname fragment production inSection3.1.1.3.

Viewer Behavior. The 'name' gives applications a way to associate commonnames with objects. The object can optionally be addressed by the value of the'name' attribute. See3.1.1.

3.2.2.8 Content

Initial value: none
Applies to: 'para', 'subpara'
Inherited: no

Description. The 'content' APS Attribute provides a means to declare what istext content in a 'para' APS and in a 'subpara' APS. It is provided as a basis on whichapplications can build text search (which is not further standardized in thisversion of WebCGM). Text that is apparent in a graphical display may notcorrespond to recognizable text strings in the metafile content itself. Forexample, the metafile content may draw the text with raster elements, or withfilled strokes, or one character at a time in random order, etc.

A 'content' attribute on a 'para' APS should contain all of the renderedtext of the 'para' APS, and a 'content' attribute on a 'subpara' APS shouldcontain all of the rendered text of the 'subpara' APS. The 'content' APSAttribute may occur only within APS of type 'para' and 'subpara', and thereshall be at most one occurrence within any such APS.

Parameters. The data record is an SDR of one member, containing one string(type SF, String Fixed).

Viewer Behavior. See the description under the 'para' APS,3.2.1.3.

3.2.2.9Visibility

Initial value: on
Applies to: 'layer', 'grobject', 'para', 'subpara'
Inherited: yes

Description. The 'visibility' attribute indicates if an object is visible ornot. 'Visibility' applies to Application Structures (APS) of type 'layer','grobject', 'para' and 'subpara'. The value of 'visibility' isinherited by any descendant objects of type'layer', 'grobject', 'para', and 'subpara'. Although it can't be set on'grnode' and doesn't apply to 'grnode', 'visibility' also inherits to objectsof type 'grnode', and inherits from objects of type 'grnode' to any descendentsin the WebCGM structure.

Parameters. The data record is an SDR of one member, containing one string(type SF, String Fixed). The valid values are 'off', 'on', 'inherit'.

Viewer behavior. A non-visible object is not displayed. For the purposes ofthis section, a non-visible object is one whose 'visibility' attribute value is'off', or one whose 'visibility' attribute value is 'inherit' with anon-visible parent. Highlight requests are ignored for non-visible objects,regardless of the source of the request (i.e., whether from Object Behaviorkeyword, or from highlight() DOM method, or from interaction feedback such asmouse-over). Visibility does not affect the ability to navigate to an object,for example by Object Behavior keywords. A non-visible object behaves like anon-interactive object (i.e., it cannot be clicked or highlighted). This doesnot imply that the'interactivity' APSattribute is changed to off, but simply that the user agent must notrespond to mouse events.

3.2.2.10Interactivity

Initial value: on
Applies to: 'layer', 'grobject', 'para', 'subpara'
Inherited: yes

Description. The 'interactivity' attribute indicates if an object mayreceive mouse events. 'Interactivity' applies to Application Structures (APS)of type 'layer', 'grobject', 'para' and 'subpara'. The value of 'interactivity'isinherited by any descendant objects oftype 'layer', 'grobject', 'para', and 'subpara'. Although it can't be set on'grnode' and doesn't apply to 'grnode', 'interactivity' also inherits toobjects of type 'grnode', and inherits from objects of type 'grnode' to anydescendents in the WebCGM structure.

Parameters. The data record is an SDR of one member, containing one string(type SF, String Fixed). The valid values are 'off', 'on', 'inherit'.

Viewer behavior. When the 'interactivity' of an object is set to off, eventsfor this object are disabled. This has the effect of disabling event handlers,cursor changes, highlighting, screentip and hyperlinking for the given node andits descendants. Regardless of the value of its 'interactivity' attribute, anobject that is the target of a link responds to highlighting requests(keywords), provided that its visibility is enabled according to the value the'visibility' APS Attribute.

3.2.2.11 About generalmetadata elements

Description. This version and level of WebCGM do not allow additional APSAttribute elements to occur, other than as enumerated above. Private metadatamay be associated with WebCGM objects by keeping the metadata outside of theCGM, and associating it with objects within the CGM. A means for bindingexternal private metadata to WebCGM instances is defined in the sectionXML Companion File (XCF).

3.3 Content model

This subsection is informative (non-normative).

This is an informative, at-a-glance summary of the whole content model ofthe CGM Version 4 functionality of WebCGM — the "Intelligence" content— using the formal specification technique of the XML DTD. It has beensuggested that validating XML parsers could be adapted to perform contentvalidation of WebCGM instances (either via modification of the readers, or viatransformation of the intelligent content of the WebCGM instance).

<!-- To document the structure of the CGM Version 4      --><!-- content of WebCGM the following DTD fragment        --><!-- has been developed.                                 --><!--                                                     --><!-- PICBODY is included in this DTD fragment for        --><!-- purposes of demonstrating that the layer, grobject, --><!-- and para structures can exist within the picture    --><!-- body level in a CGM instance. The gdata element     --><!-- with its associated cgmprim entity attribute is     --><!-- intended to represent the model for CGM data stored --><!-- as an external entity.                              --><!--                                                     --><!-- Note: of the attributes listed below, all           --><!-- correspond to APS Attribute elements of CGM, except --><!-- the 'ID', which corresponds to the 'id' parameter   --><!-- of the Begin Application Structure CGM element.     --><!ELEMENT picbody (layer+ | (grobject | para | grnode                              | gdata)*)                       ><!ELEMENT layer (grobject | para | grnode | gdata)*        ><!ATTLIST layer  id            ID         #REQUIRED  layername     CDATA      #REQUIRED  layerdesc     CDATA      #IMPLIED  visibility    (on | off | inherit) #IMPLIED  interactivity (on | off | inherit) #IMPLIED                                                              ><!ELEMENT grobject (grobject | para | grnode | gdata)*     ><!ATTLIST grobject  id            ID         #REQUIRED  region        CDATA      #IMPLIED  viewcontext   CDATA      #IMPLIED  linkuri       CDATA      #IMPLIED  screentip     CDATA      #IMPLIED  name          CDATA      #IMPLIED  visibility    (on | off | inherit) #IMPLIED  interactivity (on | off | inherit) #IMPLIED                                                              ><!ELEMENT para (subpara | gdata)*                          ><!ATTLIST para  id            ID         #REQUIRED  region        CDATA      #IMPLIED  viewcontext   CDATA      #IMPLIED  linkuri       CDATA      #IMPLIED  screentip     CDATA      #IMPLIED  name          CDATA      #IMPLIED  content       CDATA      #IMPLIED  visibility    (on | off | inherit) #IMPLIED  interactivity (on | off | inherit) #IMPLIED                                                              ><!ELEMENT subpara (gdata)*                                 ><!ATTLIST subpara  id            ID         #REQUIRED  region        CDATA      #IMPLIED  viewcontext   CDATA      #IMPLIED  linkuri       CDATA      #IMPLIED  screentip     CDATA      #IMPLIED  name          CDATA      #IMPLIED  content       CDATA      #IMPLIED  visibility    (on | off | inherit) #IMPLIED  interactivity (on | off | inherit) #IMPLIED                                                              ><!ELEMENT grnode (grobject | para | grnode | gdata)*       ><!ATTLIST grnode  id            ID         #REQUIRED                                                              ><!ELEMENT gdata EMPTY                                      ><!ATTLIST gdata  cgmprim       ENTITY     #REQUIRED                          >

Note: the use of XML to express the content model of WebCGM implies that aparticular attribute can have at most one instance within a particular APSinstance. This is not the case, and the normative rules are as specified in3.2.2.1 through3.2.2.10.

3.4 WebCGM and theobjectelement

The only standard way to reference inline CGMs from HTML documents isthrough theobject element, using thedata attributefor the CGM file and thetype attribute to specify the full MimeType. The minimal element for adding CGM into a document would be:

OtherHTML 4.01 attributes whichmay be used on theobject tag includealign,border,hspace,id,nameandvspace. Use ofalign,border,hspace, andvspace is only permitted in TransitionalHTML 4.01, not Strict HTML 4.01.

The attributesclassid,codebase,declare,shapes,usemap,codetype, andarchive are prohibited. Content whichuses WebCGM shall not make direct reference to the code which may be used todisplay it.

The event-related attributes, ONCLICK,...,ONMOUSEOVER, are permitted buttheir effect is undefined in this version of WebCGM. Instead the WebCGM DOMoffers anaddEventListener method foradding event listeners on WebCGM documents

The attributesaccesskey,alt,class,dir,lang,longdesc,standby,style,tabindex andtitle are permitted, but have no defined effect on CGM viewers anddisplay of CGM pictures. They are used to improve accessibility, and may alsoaffect the presentation of any alternative text content of theobject element.

Theobject element can contain optionalparamelements, which allow the HTML to pass additional data to the target object.The followingparam elements are defined and permitted for WebCGM.Eachparam is presented as a name followed by permissible values(after the ":"), and description. The names and the permissible values arecase-insensitive, with the single exception of the value of the'onload'param (which identifies theevent handler script function that is to be invoked upon theonload event, represented below as"<eventHandlerName(evt)>".

onload: <eventHandlerName(evt)>

The user supplies the name of an event handler that the viewer shall invoke upon the 'onload' event. Thisparam element and handler allows for script writers to manipulate the WebCGM DOM at the point at which the user agent has fully parsed theobject tag and its descendants and is ready to render the object to the screen.

EXAMPLE:

<script type="application/ecmascript"> <![CDATA[
function myHandler(evt)
{
// performs DOM manipulation calls...
}
]]>
</script>
[...]

<object data="xxx.cgm" type="image/cgm;Version=4;ProfileId=WebCGM"
                       width="200" height="100">
  <param name="onload" value="myHandler(evt);"/>
</object>

fixed: No | Yes

Disables ("Yes") or enables ("No") theuser zoom and pan controls of the viewer. It does not affect picture navigation by other means, such asobject behaviors inIRI fragments. Default is No. For the value Yes, viewers shall not put up scroll bars and zoom options, which would normally be offered.

background: Enable | Disable

States whether the CGM picture shall be drawn with its normal background color, as given in the CGM picture (Enable), or whether the background color of the picture shall be suppressed (Disable), thus allowing the background color or background image of the HTML page to show through. Default is Enable. Note: the background color of the picture is either default, or is explicitly defined by the BACKGROUND COLOUR element in the CGM picture. (Seesection 2.2.3.)

Thebackground param element isdeprecated and may be removed in a future version of this profile.

viewport: topx topy botx boty

Gives a viewport of the CGM (a part of the picture) to display. The values are the top-left and bottom-right corners of the sub-picture. The units are either in the Virtual Device Coordinates (VDC) of the CGM; or, as a percentage of the picture's VDC EXTENT element (whether explicit or default), if the value is followed by a percent sign (%). This facility allows for different parts of a CGM picture to be displayed at different scales in different places in the document. Default is full VDC EXTENT. Note: the use ofviewport can conflict with some options (e.g., those object behaviors which effectively select a sub-picture via a 'viewcontext' APS attribute within the CGM picture) in aIRI fragment on thedata attribute of theobject element. In case of conflict, theviewport specification shall have precedence.

Theviewport param element isobsolete as of version 2.1 of this profile.

mapping: fit | fill
halign: top | middle | bottom
valign: left | middle | right

Each CGM picture has a fixed aspect ratio, determined by the VDC EXTENT element, which may not agree with the aspect ratio defined byheight andwidth specified on theobject tag. These three parameters can be used to specify where and how to place the CGM within the window specified on theobject tag. 'Fit' specifies to isotropically scale the picture (or sub-picture) so that one dimension fits exactly in the window — there will be undrawn space left in the window in one dimension if the aspect ratios don't match. In this case, the handling of the extra space is defined by the values of 'halign' (if the extra space is in the horizontal dimension) and 'valign' (if the extra space is in the vertical dimension). 'Fill' means to isotropically scale so that the window is filled in both directions — if the aspect ratios don't match, a part of the picture will be clipped away at the window boundary. In this case, 'halign' and 'valign' define what part of the picture is shown (and what part is clipped away) in the dimension that needs to be clipped.

The default values are 'fit', 'middle', 'middle'.

Theseparam elements differ from thealign attribute ofobject, which is used to specify where theobject is placed in the document. This could be expressed using theparam element as:

<param name="halign" value="middle" /><param name="valign" value="middle" />

Figures 5 and 6 show the different effects achieved by 'Fit' and 'Fill' withthe different alignments.

Figure 5. Effects of fit

Figure 6. Effects of fill

4. WebCGM XML Companion File

This chapter and its sections are normative, unless otherwiseindicated.

4.1 Introduction & examples

This section and its subsections are informative(non-normative).

The WebCGM XML Companion File (XCF) was added to WebCGM in the 2.0 version,and further enhanced in this 2.1 upgrade. The element and attribute definitionsfound in this section represent the WebCGM XCF DTD. This DTD may be extended byprofiles deriving from WebCGM. The WebCGM XML companion files may be used forseveral purposes. There are many conceivable usage scenarios, but for the scopeof WebCGM, the following four were identified as most important.

Scenario 1: A companion file can be used to bindapplication specific details (such as a part number) to a particularApplication Structure. It is up to the application to control how theapplication-specific information is used.

Example4.1:A companion file used to relate some application-specific datato graphical objects.

Scenario 2: A companion file could also be used to update aCGM illustration via the WebCGM DOM (see sectionRelationship with XML companion filefor more information):

Example 4.2:A companionfile used to update sample_2.cgm before being displayed by a user agent. Callsto some WebCGM DOM methods need to take place to perform thistask.

Scenario 3: Although it is out-of-scope of this version ofthe WebCGM XCF to fully mirror the hierarchical structure of a CGM graphic (see"Structure overview"), an XML Companion File could beused as a partial, scaled down XML inventory of a CGM illustration byenumerating the Application Structures IDs, types and (most) attributes.

Example 4.3:A companionfile used as a partial inventory of sample_3.cgm. In this case, the descriptionputs an emphasis on the hotspot region of each 'grobject'element.

4.2 Content and structure of the XCF

This section and its subsections are normative, unless otherwiseindicated.

4.2.1 Structure overview

It is not the intent of the WebCGM XML Companion File (XCF) to be a faithfulXML representation of the object tree in a hierarchical WebCGM. Rather, XCFprovides a mechanism to externalize both standardized and application (private)metadata from a structured WebCGM instance, and to bind it to the properobjects in the object tree of the WebCGM instance.

Accordingly, the structure of the XML Companion File is mostly flat. Afterthe root element,webcgm, the variousstandardXCF elements occur as siblings in the companion file (with the singleexception oflinkuri). So, for example,grobjects that have a parent-child relationship in the CGM aresiblings in the XCF. The normative WebCGM DTD for XCF expresses and enforcesthis flat structure, independent of whatever hierarchy may exist in thecorresponding WebCGM instance.

Example 4.4:Amostly-flat companion file binds standardized metadata to a hierarchical objecttree in a WebCGM instance.

BegPic  ..(graphics etc)..  BegAps type="grobject"    BegAps type="grobject"      ..(graphics etc)..      BegAps type="grobject"        BegAps type="grobject"          ..(graphics etc)..        EndAps      EndAps    EndAps  EndApsEndPic

Note: Example 4.4 uses a condensed schematic representation of the CGM code,eliminating numerous details in order to illustrate the point.

Example 4.4 illustrates another point about the relationship of the XCFcontents to the corresponding WebCGM instance — the order of the XCF isnot required to follow the order of the CGM contents.

As suggested by Example 4.4, the root element of a conforming XCF instancemust be thewebcgm element. Thewebcgm element corresponds to the Picture object in the CGM. SeeRelationship with XML CompanionFile for more discussion.

The next section deals in detail with application-specific metadataattributes and elements in an XCF. In order to unambiguously establish where inthe WebCGM object tree those metadata are to be inserted, theapplication-specific attributes and elements (defined in a separate namespace)are placed in the XCF as attributes and child elements on standardized XCFelements that correspond (bind) to the appropriate object in the WebCGM. Thisis seen in example 4.1, for application-specific attributes. See also sectionRelationship with XML CompanionFile for more discussion.

4.2.2 Extending the XML CompanionFile

The WebCGM DTD is extensible so that application-specific orindustry-specific metadata may be added to the WebCGM object model (as shown inexample 4.1). The extension definitions are implemented using namespaces. TheDTD defines an extension entity for the content and attributes of mostelements. As an example, a part manufacturer may want to associate partsinformation to graphical objects. This might be implemented with an extensionthat looks like:

<!ENTITY   % grobjectAttEXT   "model:partNum CDATA #IMPLIED" >

A host application could query the WebCGM DOM and retrieve the associatedpart information.

A set of rules must be followed when extending the WebCGM DTD:

1. The root element MUST be 'webcgm'.
2. The extended elements and/or attributes MUST be in another namespace (SeeNamespaces in XML).
3. Extending the list of children of an element MUST use theelementNameEXT entity.
4. Extending the attribute list of an element MUST use theelementNameAttEXT entity.
5. Elements from the WebCGM namespace MUST NOT be descendants of other namespaced elements.

The rules found above allow WebCGM user agents to process extended companionfiles in an interoperable manner.

4.2.3 The WebCGM XCF namespace

The WebCGM namespace:

http://www.cgmopen.org/schema/webcgm/

Namespace example:

<webcgm version="2.1" filename="sample.cgm"xmlns="http://www.cgmopen.org/schema/webcgm/">

Public Identifier for WebCGM 2.1:

PUBLIC "-//OASIS//DTD WebCGM 2.1//EN"

System Identifier for the WebCGM 2.1:

http://docs.oasis-open.org/webcgm/v2.1/webcgm21.dtd

DOCTYPE example. The following is an example document typedeclaration for a WebCGM XCF document:

<!DOCTYPE webcgm PUBLIC "-//OASIS//DTDWebCGM 2.1//EN""http://docs.oasis-open.org/webcgm/v2.1/webcgm21.dtd">

4.2.4 WebCGM XML Companion Fileconformance

A file is a conforming WebCGM 2.1 XCF document if it adheres to thespecifications described in this (WebCGM 2.1) document, including those in theWebCGM 2.1 XCF DTD, and in addition all of thefollowing conditions are met:

• it is a well-formed XML document (according toExtensible Markup Language (XML) 1.0 [XML10];
• its root element iswebcgm
• if all non-WebCGM namespace elements and attributes and allxmlns attributes which refer to non-WebCGM namespaces are removed from the given document, and if anappropriate document type declaration (i.e., <!DOCTYPE webcgm ... >) which points to the WebCGM DTD is included immediately after the XML declaration (i.e., <?xml...?>), the result is avalid XML document.
• it conforms toNamespaces in XML, if any namespaces other than WebCGM are used in the document.

4.3XCF elements

This section and its subsections are normative, unless otherwiseindicated.

The standard XCF elements include:

• the standard root element,webcgm
• elements whose names match corresponding WebCGM object (APS) types —layer,grobject,para,subpara
• and a pair of general purpose metadata binding elements —bindById andbindByName.

The standard XCF elements also include:

• linkuri. Linkuri is an APS Attribute, but is encoded as an XCF element, rather than attribute, to avoid what would otherwise be an overly complex encoding of the string that would comprise its value as an XML attribute.

4.3.1 Data types andencoding

For the standardized XCF content, most of the items expressed on XCFelements as XML attributes have a straightforward correlation to a standardizedWebCGM attribute or property that may be set or inquired with a WebCGMDOMcall.

In general, the encoding of XML attributes on XCF elements is identical tothe encoding of the corresponding parameters in DOM calls. For example, theWebCGMAppStructure interface (section 5.7.6)defines 'viewcontext' as a simple string of four numbers, whitespace separated(seeWsp definition, section 5.5). Theencoding of 'viewcontext' as an XML attribute on any allowed XCF element is thesame as its encoding as a DOM method parameter.

Similarly, theStyleProperties (settable on the WebCGMPicture and WebCGMAppStructureinterfaces), as XML attributes on the XCF elements have the same valid valuesand are encoded identically as in the corresponding DOM calls.

The single exception to the use of consistent encodings is for the'linkuri' APS attribute, which is encoded as an element inthe XCF, for reasons as explained.

See theWebCGM DOM data types sectionfor complete details.

4.3.2Conventions used

Most of the XCF elements may haveStyle Properties as XML attributes(Style Properties are defined and supported on the DOMWebCGMPicture andWebCGMAppStructure interfaces.) Thefollowing entity definition is used in the DTD snippets of the subsequentsubsections, on those elements which support Style Properties at both the APSlevel and Picture level. (The background-color Style Property that applies onlyat the Picture level.)

<!ENTITY % styleProperties                   "text-size            CDATA        #IMPLIED                    fill-color           CDATA        #IMPLIED                    intensity            CDATA        #IMPLIED                    stroke-color         CDATA        #IMPLIED                    stroke-weight        CDATA        #IMPLIED                    text-color           CDATA        #IMPLIED                    text-font            CDATA        #IMPLIED                    raster-intensity     CDATA        #IMPLIED                    stroke-type          CDATA        #IMPLIED                    stroke-offset        CDATA        #IMPLIED                    interior-style       CDATA        #IMPLIED                    hatch-index          CDATA        #IMPLIED                    pattern-index        CDATA        #IMPLIED                    edge-visibility      CDATA        #IMPLIED                    fill-offset          CDATA        #IMPLIED">

A single WebCGM XCF element must not contain both theintensityproperty and one or more of the overlapping propertiesfill-color,stroke-color,text-color. Overlapping properties mayoccur sequentially on different XCF elements, and then their processing isdefined by their order of occurrence (seeStyle Properties description).

See "Data types and encoding" for more aboutStyle Properties.

4.3.3The 'webcgm' element

A WebCGM companion file (or any other CGM profile derived from the WebCGMprofile) must have a 'webcgm' element as the root element. The 'webcgm' elementcorresponds to the Picture node in the WebCGM DOM tree (see for example theWebCGMPicture interface in the DOM).

<!ENTITY % webcgmEXT "" ><!ENTITY % webcgmAttEXT "" ><!ELEMENT webcgm ( (layer | grobject | para | subpara | bindById | bindByName %webcgmEXT;)* ) ><!ATTLIST webcgm  id       ID    #IMPLIED                  version  CDATA #FIXED '2.1'                  filename CDATA #IMPLIED                  xmlns    CDATA #FIXED "http://www.cgmopen.org/schema/webcgm/"                  background-color  CDATA  #IMPLIED                  pictureVisibility    ( on | off) #IMPLIED                  %styleProperties;                  %webcgmAttEXT;>

Attribute definitions:

id="xml:id"
Standard XML attribute for assigning a unique identifier to an element. RefertoExtensible Markup Language (XML) 1.0 [XML10].
version="CDATA"
Represents the version of the WebCGM specification. The value is 2.1 for thisspecification. Every conforming XCF must identify its version, either byincluding this attribute on the webcgm element, or by including aDOCTYPE pointing to this WebCGM XCF's DTD, or both(recommended). An industry-specific profile derived from this WebCGM XCFspecification must not use this attribute to identify its version, and shoulddefine and require use of a namespace attribute to identify its profileversion. For example, if ASD includes in its future version of S1000D "n.m" anXCF derived from WebCGM 2.1, thewebcgm tag might look likethis:

<webcgm version="2.1" asd:s1000d-version="n.m" xmlns:asd="http://example.org/asd/" ...>

filename="CDATA"
Represents the filename of the corresponding WebCGM file. 'filename' is adescriptive attribute.
xmlns[:prefix]="CDATA"
Standard XML attribute whose value defines the "resource-name" for identifyingan XML namespace. Refer toNamespaces in XML. The 'xmlns'attribute without prefix identifies the (default)WebCGMnamespace, and (with prefix) must be used to identify the foreignnamespace(s) of anyapplication-specific metadata thatare used in the XCF instance. Note that the value given in theDTD snippet, and the attribute type (#FIXED),apply only to the unprefixed, default WebCGM namespace.

<webcgm version="2.1" xmlns="http://www.cgmopen.org/schema/webcgm/"                      xmlns:asd="http://example.org/asd/" ...><xcf:webcgm version="2.1" xmlns:asd="http://example.org/asd/"                           ...>

background-color="CDATA"
background-color is aStyleProperty for setting the background color of the Picture (root node ofWebCGM object tree).
pictureVisibility="on|off"
Defines the visibility for the picture that corresponds to thewebcgm element of this XCF. This is similar to the 'visibility'APS Attribute that can be applied to metafile Application Structures, except itapplies to the picture (on which the 'visibility' APS Attribute is not allowedby CGM rules.) The effect is the same as the invocation of thesetPictureVisibility method on theWebCGMPicture interface of the DOM. .
styleProperties
the styleProperties entity collectively defines thoseStyle Properties that apply atboth the Picture level and the object/APS level.
webcgmEXT
the webcgmEXT entity is a mechanism for adding additional child content (i.e.,metadata) on the root node.
webcgmAttEXT
the webcgmAttEXT entity is a mechanism for adding additional attributes (i.e.,metadata) on the root node.

4.3.4The 'layer' element

The 'layer' element of an XML companion file represents a CGM ApplicationStructure of type 'layer'. The corresponding 'layer' is identifiable given itsassigned 'apsid' attribute value.

<!ENTITY % layerEXT "EMPTY" ><!ENTITY % layerAttEXT ""   ><!ELEMENT layer %layerEXT;  ><!ATTLIST layer apsid         ID           #REQUIRED                layerdesc     CDATA        #IMPLIED                visibility    ( on | off  | inherit) #IMPLIED                interactivity ( on | off  | inherit) #IMPLIED                %styleProperties;                %layerAttEXT;>

Attribute definitions:
apsid="xml:id"
The unique identifier of the Application Structure for the given WebCGMfile.
layerdesc="CDATA"
Value of the 'layerdesc' Application Structure attribute for the associatedAPS.
visibility="on|off|inherit"
Value of the 'visibility' Application Structure attribute for the associatedAPS.
interactivity="on|off|inherit"
Value of the 'interactivity' Application Structure attribute for the associatedAPS.
styleProperties
the styleProperties entity collectively defines thoseStyle Properties that apply atboth the Picture level and the object/APS level.
layerEXT
the layerEXT entity is a mechanism for adding additional child content (i.e.,metadata) on the 'layer'.
layerAttEXT
the layerAttEXT entity is a mechanism for adding additional attributes (i.e.,metadata) on the 'layer'.

See also the'layer' functionaldescription in Section 3.

4.3.5The 'grobject' element

The 'grobject' element of an XML companion file represents a CGM ApplicationStructure of type 'grobject'. The corresponding grobject' is identifiable givenits assigned 'apsid' attribute value.

<!ENTITY % grobjectEXT "" ><!ENTITY % grobjectAttEXT "" ><!ELEMENT grobject ( linkuri %grobjectEXT; )* ><!ATTLIST grobject  apsid         ID           #REQUIRED                    screentip     CDATA        #IMPLIED                    region        CDATA        #IMPLIED                    viewcontext   CDATA        #IMPLIED                    visibility    ( on | off | inherit) #IMPLIED                    interactivity ( on | off | inherit) #IMPLIED                    %styleProperties;                    %grobjectAttEXT;>

Attribute definitions:
apsid="xml:id"
The unique identifier of the Application Structure for the given WebCGMfile.
screentip="CDATA"
Value of the 'screentip' Application Structure attribute for the associatedAPS.
region="CDATA"
Value of the 'region' Application Structure attribute for the associatedAPS.
viewcontext="CDATA"
Value of the 'viewcontext' Application Structure attribute for the associatedAPS.
visibility="on|off|inherit"
Value of the 'visibility' Application Structure attribute for the associatedAPS.
interactivity="on|off|inherit"
Value of the 'interactivity' Application Structure attribute for the associatedAPS.
styleProperties
the styleProperties entity collectively defines thoseStyle Properties that apply atboth the Picture level and the object/APS level.
grobjectEXT
the grobjectEXT entity is a mechanism for adding additional child content(i.e., metadata) on the 'grobject'.
grobjectAttEXT
the grobjectAttEXT entity is a mechanism for adding additional attributes(i.e., metadata) on the 'grobject'.

See also the'grobject' functionaldescription in Section 3.

4.3.6The 'para' element

The 'para' element of an XML companion file represents a CGM ApplicationStructure of type 'para'. The corresponding 'para' is identifiable given itsassigned 'apsid' attribute value.

<!ENTITY % paraEXT "" ><!ENTITY % paraAttEXT "" ><!ELEMENT para ( linkuri %paraEXT; )* ><!ATTLIST para apsid         ID           #REQUIRED               screentip     CDATA        #IMPLIED               region        CDATA        #IMPLIED               viewcontext   CDATA        #IMPLIED               visibility    ( on | off | inherit) #IMPLIED               interactivity ( on | off | inherit) #IMPLIED               %styleProperties;               %paraAttEXT;>

Attribute definitions:
apsid="xml:id"
The unique identifier of the Application Structure for the given WebCGMfile.
screentip="CDATA"
Value of the 'screentip' Application Structure attribute for the associatedAPS.
region="CDATA"
Value of the 'region' Application Structure attribute for theassociated APS.
viewcontext="CDATA"
Value of the 'viewcontext' Application Structure attribute for theassociated APS.
visibility="on|off|inherit"
Value of the 'visibility' Application Structure attribute for the associatedAPS.
interactivity="on|off|inherit"
Value of the 'interactivity' Application Structure attribute for the associatedAPS.
styleProperties
the styleProperties entity collectively defines thoseStyle Properties that apply atboth the Picture level and the object/APS level.
paraEXT
the paraEXT entity is a mechanism for adding additional child content (i.e.,metadata) on the 'para'.
paraAttEXT
the paraAttEXT entity is a mechanism for adding additional attributes (i.e.,metadata) on the 'para'.

See also the'para' functionaldescription in Section 3.

4.3.7The 'subpara' element

The 'subpara' element of an XML companion file represents a CGM ApplicationStructure of type 'subpara'. The corresponding 'subpara' is identifiable givenits assigned 'apsid' attribute value.

<!ENTITY % subparaEXT "" >      <!ENTITY % subparaAttEXT "" >      <!ELEMENT subpara ( linkuri %subparaEXT; )* >      <!ATTLIST subpara apsid         ID           #REQUIRED                  screentip     CDATA        #IMPLIED                  region        CDATA        #IMPLIED                  viewcontext   CDATA        #IMPLIED                  visibility    ( on | off | inherit) #IMPLIED                  interactivity ( on | off | inherit) #IMPLIED                  %styleProperties;                  %subparaAttEXT;>

Attribute definitions:
apsid="xml:id"
The unique identifier of a the Application Structure for the given WebCGMfile.
screentip="CDATA"
Value of the 'screentip' Application Structure attribute for the associatedAPS.
region="CDATA"
Value of the 'region' Application Structure attribute for the associatedAPS.
viewcontext="CDATA"
Value of the 'viewcontext' Application Structure attribute for the associatedAPS.
visibility="on|off|inherit"
Value of the 'visibility' Application Structure attribute for the associatedAPS.
interactivity="on|off|inherit"
Value of the 'interactivity' Application Structure attribute for the associatedAPS.
styleProperties
the styleProperties entity collectively defines thoseStyle Properties that apply atboth the Picture level and the object/APS level.
subparaEXT
the subparaEXT entity is a mechanism for adding additional child content (i.e.,metadata) on the 'subpara'.
subparaAttEXT
the subparaAttEXT entity is a mechanism for adding additional attributes (i.e.,metadata) on the 'subpara'.

See also the'subpara' functionaldescription in Section 3.

4.3.8The 'linkuri' element

A 'linkuri' element of an XML companion file represents a WebCGM 'linkuri'Application Structure attribute. Contrary to other attributes, the 'linkuri'attribute is expressed as an element in the XML companion file. Thecorresponding Application Structure of this 'linkuri' is its parent element.

<!ENTITY % linkuriEXT "" >
<!ENTITY % linkuriAttEXT "" >
<!ELEMENT linkuri %linkuriEXT; >
<!ATTLIST linkuri uri      CDATA #REQUIRED
                  behavior CDATA #IMPLIED
                  desc     CDATA #IMPLIED
                  %linkuriAttEXT;
>

Attribute definitions:
uri="CDATA"
TheIRI ofthis 'linkuri' attribute. See sectionBasic Data Types for moreinformation.
behavior="CDATA"
The behavior of this 'linkuri' attribute. See sectionBasic Data Types for moreinformation.
desc="CDATA"
The title or description of this 'linkuri' attribute. See sectionBasic Data Types for moreinformation.
linkuriEXT
the linkuriEXT entity is a mechanism for adding additional child content (i.e.,metadata) on the 'linkuri'.
linkuriAttEXT
the linkuriAttEXT entity is a mechanism for adding additional attributes (i.e.,metadata) on the 'linkuri'.

See also the'linkuri' functionaldescription in Section 3.

4.3.9The 'bindByName' element

A 'bindByName' element of an XML companion file is intended to correspond toone or more Application Structure in a CGM file. The common link between thoseApplication Structures is that their 'name' or 'layername' attribute valuecorresponds to 'apstargetname'. See sectionRelationship with XML companion filefor more information on the rules of mapping 'bindByName' attributes to WebCGMApplication Structures.

<!ENTITY % bindByNameEXT "" >
<!ENTITY % bindByNameAttEXT "" >
<!ELEMENT bindByName ( linkuri %bindByNameEXT; )* >
<!ATTLIST bindByName apstargetname CDATA        #REQUIRED
                     screentip     CDATA        #IMPLIED
                     region        CDATA        #IMPLIED
                     viewcontext   CDATA        #IMPLIED
                     layerdesc     CDATA        #IMPLIED
                     visibility    ( on | off | inherit) #IMPLIED
                     interactivity ( on | off | inherit) #IMPLIED                     %styleProperties;
                     %bindByNameAttEXT;>

Attribute definitions:
apstargetname="CDATA"
Name used to identify the corresponding Application Structure(s) for a givenWebCGM file.
screentip="CDATA"
Value of the 'screentip' Application Structure attribute for the associatedAPS.
region="CDATA"
Value of the 'region' Application Structure attribute for the associatedAPS.
viewcontext="CDATA"
Value of the 'viewcontext' Application Structure attribute for the associatedAPS.
layerdesc="CDATA"
Value of the 'layerdesc' Application Structure attribute for the associatedAPS.
visibility="on|off|inherit"
Value of the 'visibility' Application Structure attribute for the associatedAPS.
interactivity="on|off|inherit"
Value of the 'interactivity' Application Structure attribute for the associatedAPS.
styleProperties
the styleProperties entity collectively defines thoseStyle Properties that apply atboth the Picture level and the object/APS level.
bindByNameEXT
the bindByNameEXT entity is a mechanism for adding additional child content(i.e., metadata) on the APS.
bindByNameAttEXT
the bindByNameAttEXT entity is a mechanism for adding additional attributes(i.e., metadata) on the APS.

4.3.10The 'bindById' element

The 'bindById' element of an XML companion file represents a CGM ApplicationStructure one of the types: layer, grobject, para, subpara. APS of type'grnode' are valid in a 'bindById' element. The corresponding object isidentifiable given its assigned 'apsid' attribute value. See sectionRelationship with XML companion filefor more information on the rules of mapping 'bindById' attributes to WebCGMApplication Structures.

<!ENTITY % bindByIdEXT "" >
<!ENTITY % bindByIdAttEXT "" >
<!ELEMENT bindById ( linkuri %bindByIdEXT; )* >
<!ATTLIST bindById apsid         ID           #REQUIRED
                   screentip     CDATA        #IMPLIED
                   region        CDATA        #IMPLIED
                   viewcontext   CDATA        #IMPLIED
                   layerdesc     CDATA        #IMPLIED
                   visibility    ( on | off | inherit) #IMPLIED
                   interactivity ( on | off | inherit) #IMPLIED                   %styleProperties;
                   %bindByIdAttEXT;>

Attribute definitions:
apsid="xml:id"
The unique identifier of the Application Structure for the given WebCGMfile.
screentip="CDATA"
Value of the 'screentip' Application Structure attribute for the associatedAPS.
region="CDATA"
Value of the 'region' Application Structure attribute for the associatedAPS.
viewcontext="CDATA"
Value of the 'viewcontext' Application Structure attribute for the associatedAPS.
layerdesc="CDATA"
Value of the 'layerdesc' Application Structure attribute for the associatedAPS.
visibility="on|off|inherit"
Value of the 'visibility' Application Structure attribute for the associatedAPS.
interactivity="on|off|inherit"
Value of the 'interactivity' Application Structure attribute for the associatedAPS.
styleProperties
the styleProperties entity collectively defines thoseStyle Properties that apply atboth the Picture level and the object/APS level.
bindByIdEXT
the bindByIdEXT entity is a mechanism for adding additional child content(i.e., metadata) on the APS.
bindByIdAttEXT
the bindByIdAttEXT entity is a mechanism for adding additional attributes(i.e., metadata) on the APS.

4.4 The complete XCF DTD

This section is normative.

The complete WebCGM XML Companion File (XCF) DTD follows.

<?xml version="1.0" encoding="UTF-8"?><!-- ================================================================ --><!-- This is the WebCGM XML Companion File DTD for use with           --><!-- WebCGM 2.1                                                       --><!-- ================================================================ --><!-- Original issue: March 2008                                       --><!--                                                                  --><!-- Revision history:                                                --><!--        June 2008 - updated for CD02 changes to DOM and XCF.      --><!--        November 2009 - removed geometricTransform from the XCF.  --><!--                                                                  --><!-- ================================================================ --><!--                                                                  --><!-- ================================================================ --><!-- Application specific entities                                    --><!-- Application groups define application specific attributes here   --><!-- and define the stubs for application specific elements that      --><!-- will be defined later in the DTD                                 --><!--                                                                  --><!ENTITY % webcgmEXT ""                                                 ><!ENTITY % webcgmAttEXT ""                                              ><!ENTITY % layerEXT "EMPTY"                                             ><!ENTITY % layerAttEXT ""                                               ><!ENTITY % grobjectEXT ""                                               ><!ENTITY % grobjectAttEXT ""                                            ><!ENTITY % paraEXT ""                                                   ><!ENTITY % paraAttEXT ""                                                ><!ENTITY % subparaEXT ""                                                ><!ENTITY % subparaAttEXT ""                                             ><!ENTITY % linkuriEXT "EMPTY"                                           ><!ENTITY % linkuriAttEXT ""                                             ><!ENTITY % bindByIdEXT ""                                               ><!ENTITY % bindByIdAttEXT ""                                            ><!ENTITY % bindByNameEXT ""                                             ><!ENTITY % bindByNameAttEXT ""                                          ><!ENTITY % styleProperties                   "text-size            CDATA        #IMPLIED                    fill-color           CDATA        #IMPLIED                    intensity            CDATA        #IMPLIED                    stroke-color         CDATA        #IMPLIED                    stroke-weight        CDATA        #IMPLIED                    text-color           CDATA        #IMPLIED                    text-font            CDATA        #IMPLIED                    raster-intensity     CDATA        #IMPLIED                    stroke-type          CDATA        #IMPLIED                    stroke-offset        CDATA        #IMPLIED                    interior-style       CDATA        #IMPLIED                    hatch-index          CDATA        #IMPLIED                    pattern-index        CDATA        #IMPLIED                    edge-visibility      CDATA        #IMPLIED                    fill-offset          CDATA        #IMPLIED"         >

<!--                                                                  --><!ELEMENT webcgm ( (layer | grobject | para | subpara |                     bindById | bindByName %webcgmEXT;)* )               ><!ATTLIST webcgm id       ID    #IMPLIED                 version  CDATA #FIXED '2.1'                 filename CDATA #IMPLIED                 background-color CDATA #IMPLIED                 pictureVisibility ( on | off ) #IMPLIED                 xmlns    CDATA #FIXED "http://www.cgmopen.org/schema/webcgm/"                 %styleProperties;                 %webcgmAttEXT;                                         ><!ELEMENT layer %layerEXT;                                              ><!ATTLIST layer apsid         ID           #REQUIRED                layerdesc     CDATA        #IMPLIED                visibility    ( on | off | inherit) #IMPLIED                interactivity ( on | off | inherit) #IMPLIED                %styleProperties;                %layerAttEXT;                                           ><!ELEMENT grobject ( linkuri %grobjectEXT; )*                           ><!ATTLIST grobject apsid         ID           #REQUIRED                   screentip     CDATA        #IMPLIED                   region        CDATA        #IMPLIED                   viewcontext   CDATA        #IMPLIED                   visibility    ( on | off | inherit) #IMPLIED                   interactivity ( on | off | inherit) #IMPLIED                   %styleProperties;                   %grobjectAttEXT;                                     ><!ELEMENT linkuri %linkuriEXT;                                          ><!ATTLIST linkuri uri      CDATA #REQUIRED                  behavior CDATA #IMPLIED                  desc     CDATA #IMPLIED                                                 %linkuriAttEXT;                                       ><!ELEMENT para ( linkuri %paraEXT; )*                                   ><!ATTLIST para apsid       ID           #REQUIRED               screentip     CDATA        #IMPLIED               region        CDATA        #IMPLIED               viewcontext   CDATA        #IMPLIED               visibility    ( on | off | inherit) #IMPLIED               interactivity ( on | off | inherit) #IMPLIED               %styleProperties;               %paraAttEXT;                                             ><!ELEMENT subpara ( linkuri %subparaEXT; )*                             ><!ATTLIST subpara apsid         ID           #REQUIRED                  screentip     CDATA        #IMPLIED                  region        CDATA        #IMPLIED                  viewcontext   CDATA        #IMPLIED                  visibility    ( on | off | inherit) #IMPLIED                  interactivity ( on | off | inherit) #IMPLIED                  %styleProperties;                  %subparaAttEXT;                                       ><!ELEMENT bindById ( linkuri %bindByIdEXT; )*                           ><!ATTLIST bindById apsid         ID           #REQUIRED                   screentip     CDATA        #IMPLIED                   layerdesc     CDATA        #IMPLIED                   region        CDATA        #IMPLIED                   viewcontext   CDATA        #IMPLIED                   visibility    ( on | off | inherit) #IMPLIED                   interactivity ( on | off | inherit) #IMPLIED                   %styleProperties;                   %bindByIdAttEXT;                                     ><!ELEMENT bindByName ( linkuri %bindByNameEXT; )*                       ><!ATTLIST bindByName apstargetname CDATA        #REQUIRED                     screentip     CDATA        #IMPLIED                     layerdesc     CDATA        #IMPLIED                     region        CDATA        #IMPLIED                     viewcontext   CDATA        #IMPLIED                     visibility    ( on | off | inherit) #IMPLIED                     interactivity ( on | off | inherit) #IMPLIED                     %styleProperties;                     %bindByNameAttEXT;                                 ><!--                                                                  --><!-- Define content models for application specific elements          --><!--                                                                  -->

5. WebCGM Document Object Model (DOM)

This chapter and its sections are normative, unless otherwiseindicated.

5.1Overview

This section is informative (non-normative).

This chapter defines a set of objects and interfaces for accessing andmanipulating WebCGM documents. The functionality specified in this sectionenables script writers to manipulate WebCGM documents and access informationfound in standard WebCGM XML companion files. The WebCGM DOM API focuses itsmethods on: tree traversal, style changes, and providing access to metadata.

5.2Relationship with XML DOM

This section is informative (non-normative).

Although inspired by the XML DOM specifications, the WebCGM DOM remainsoriented towards WebCGM specific functionality. Since WebCGM uses a treestructure to group graphical primitives, it was therefore appropriate, to use aset of interfaces similar to the XML DOM Node, Element and Document interfaces.However, since WebCGM is expressed in a non-XML syntax, several changes had tobe made to commonly known interfaces and methods in order to improve the userexperience of WebCGM script writers.

The WebCGM DOM could almost be perceived as a 'readonly' DOM. Some interfacemethods allow users to change the visual appearance of Application Structures,but unlike the XML DOM specification, it does not allow for removal orinsertion of WebCGMNodes into the object model. This constitute a significantdifference between the specifications.

While WebCGM 1.0 offered interactivity support via hyperlinking andhighlighting, the WebCGM 2.0 DOM took it to the next level. WebCGM 2.1 furtherenhances the DOM. The WebCGM DOM borrows concepts from theDOM3Events specification, and introduces the concept of EventListeners andmouse Events in order to meet the requirements of WebCGM users.

5.3 Relationship with XML companionfile

The WebCGM DOM is designed to provide access to XML metadata found in XMLCompanion Files. Practice has shown that some CGM illustrations are easier tomaintain if some of the non graphical information remains outside theillustration. An example of such information could be; language sensitivescreentips. The WebCGM DOM can then be used to 'apply' the information from theXML companion file to the WebCGM document (see Example 5.3) . For moreinformation on XML companion file syntax, please refer toChapter 4, WebCGM XML CompanionFile.

Another benefit of the XML Companion File is to carry application specificdata (or metadata) concerning a WebCGM illustration (see Example 4.2). Thisinformation is expressed using namespace attributes and elements in the XMLCompanion File. The WebCGM DOM provides a method for loading the XML metadatainto the user agent's object model. Using the WebCGM DOM, a user can gainaccess to the metadata. Here is a detailed example to better illustrate theconcept.

BEGMF 'example.cgm'; ...BEGPIC 'Picture 1'; ...BEGAPS 'L1' 'layer' STLIST;  APSATTR 'layername' "14 1 'Standard layer'";  BEGAPSBODY;  BEGAPS 'G1' 'grobject' STLIST;    BEGAPSBODY;    LINE 210,265 210,200 300,200;    LINE 300,200 300,265 210,265;  ENDAPS;ENDAPS; ...ENDPIC; ...ENDMF;

The in-memory tree representation of this illustration should be similar tothe illustration found below. The metafile contains a picture, the picturecontains a child node Application Structure of type layer, and the layercontains a child node Application Structure of type grobject, as illustrated inFigure 7.

Figure 7. Original tree structure

<webcgm xmlns:wiring="http://www.example.org">  <grobject apsid="G1" screentip="A new screentip">    <wiring:data wire-bundle="E132-NAV"/>  </grobject></webcgm>

The WebCGM DOM provides methods for 'applying' an XML Companion File, likethe one shown in example 5.1b, to a picture in a WebCGM document. A conforminguser agent is expected to load and parse the XML Companion File and possibly'apply' updates from the XML Companion File to the user agent's object model. Auser may want to apply a companion file for the following reasons:

i) To replace standard Application Structure Attribute values present in theWebCGM instance with new values from the XML Companion File.

ii) To supply standard Application Structure Attribute values to ApplicationStructures which do not contain attribute values with values from the XMLcompanion file.

iii) To transiently modify the Style Properties (stoke-color, text-size,etc) with which an object (APS or picture) is displayed.

iv) To add XML metadata to the user agent's object model to be retrieved ata later stage using WebCGM DOM APIs.

Once the user agent has loaded the XML Companion File into its memory model,the tree should resemble this:

Figure 8. New tree structure

The overall set of rules that a user agent must follow when applying an XMLCompanion File is as follows:

1. Verify that root element is <webcgm>, else stop further processing and throw FILE_INVALID_ERR exception.
2. Process unknown attributes if any on root element, see below aboutprocessing namespace attributes.
3. Process all child elements using a depth-first algorithm.

More specific rules forprocessing namespace attributesare:

1. If the target APS is not present in the CGM file, all attributes of the current element are ignored.
2. If the attribute is not part of the base WebCGM DTD, it must be an extended namespace attribute, else the attribute is ignored.
3. An attribute that already exists on the corresponding APS must be updated with the new attribute value.
4. In the case where an attribute with the same local name and namespace IRI is already present on the APS, its prefix is changed to be the prefix part of the qualifiedName, and its value is changed to be the attribute value. If the attribute does not exist on the APS, the namespace attribute is appended onto the APS.

More specific rules forprocessing child elements are:

1. The target APS (the parent element) must be present in the CGM file, if that is not the case, all child elements of the current element are ignored.
2. The target APS must not be of type 'grnode'. Type 'grnode' elements are not accessible via XCF. Nor are they accessible via most DOM calls, with the principal exception of theWebCGMNode interface (firstChild, nextSibling, etc).
3. If the element is not part of the base WebCGM DTD, it must be an extended namespace element. Namespace elements and their attributes are appended at the end of the target's list of child elements.
4. Elements that are defined in the WebCGM DTD are processed as follows:
   • namespace attributes are processed as specified above.
   • attributes relevant to this element, are updated on the APS.
   • other attributes are ignored.
5. If the element is a <linkuri>, the following rules apply:
   • If one or more 'linkuri' attribute(s) already exist on the parent element, they are all deleted and replaced with the corresponding set of 'linkuri's from the XCF. It is not possible to add links from the XCF to already existing links.
   • The attributes of each <linkuri> element are combined to create a single WebCGM 'linkuri' APS attribute (as defined in WebCGM 1.0) on the parent element.
6. If the element is a <bindById>, only namespace attributes and attributes relevant to the target APS type are added to the target (i.e., if the <bindById> has a 'screentip' attribute and the target APS is of type 'layer', the 'screentip' attribute will be ignored).
7. If the element is a <bindByName>, the user agent has to find all Application Structures that have a matching 'name' or 'layername' attribute. All found Application Structures are then subject to new attribute values (refer to the <bindById> description above).

5.4 Inheritance of APS Attributes and of StyleProperties

This section describes howAPS Attributes areinherited in a WebCGM structure tree. It also describes howStyle Properties are inherited, which is similarbut differs in a few key details. The inheritance models are based closely onthe inheritance model ofCSS 2.0. Somedetails have been adapted to the particulars of the WebCGM format. This chapteris the normative reference for inheritance ofAPSAttributes and ofStyle Properties inWebCGM.

5.4.1 Specified, computed, and actual values ofStyle Properties

WebCGM user agents are required to support the inheritance model defined inthis section foreligible Style Properties. Oncea user agent has loaded a document and constructed a document tree, it mustassign, for every Application Structure in the tree, a value to every StyleProperty.

Very similar to the CSS model, the final value of a Style Properties is theresult of a four-step calculation: the value is determined throughspecification (the "Specified Value"), then resolved into a value that may beused for inheritance (the "Computed Value"), then converted into an absolutevalue if necessary (the "Used Value"), and finally transformed according to thelimitations of the local environment (the "Actual Value").

5.4.1.1 Specified Values ofStyle Properties

User agents must first assign a Specified Value to each Style Property basedon the following mechanisms (in order of precedence):

1. If the Style Property is assigned a value (via a DOM call, or via an XCF), use it.
2. Otherwise, if the Style Property is inherited (i.e., its definition includes "Inherited:yes") and the Application Structure is not the root of the document tree, use the Computed Value of the parent Application Structure.
3. Otherwise use the Style Property's Initial Value. The Initial Value of each Property is indicated in the Style Property's definition.

Note: In the context of WebCGM inheritance, the root of the document tree isthe Picture node.

5.4.1.2 Computed Values ofStyle Properties

Specified Values are resolved to Computed Values after the document tree iscreated.

• When the Specified Value is not 'inherit', the Computed Value of a Style Property is determined as specified by the Computed Value line in the definition of the Property.
• When the Specified Value is 'inherit', it must be replaced for the Computed Value as defined below in thesection on inheritance.

The Computed Value exists even when the property doesn't apply, as definedby the 'Applies To' line.

5.4.1.3 Used Values of StyleProperties

In the CSS2 model from which the WebCGM model is derived, Computed Valuescan be relative to each other; for example a width could be set as apercentage, which is dependent on the containing block's width. The Used Valueis the result of taking the Computed Value and resolving these dependenciesinto a final absolute value used for the actual display. In this version ofWebCGM, there are no examples where Used Value differs from the Computed Value.This may change in a future version of the specification.

5.4.1.4 Actual Values of StyleProperties

A Used Value is in principle the value used for rendering, but a user agentmay not be able to make use of the value in a given environment. For example, auser agent may only be able to render borders with integer pixel widths and maytherefore have to approximate the computed width, or the user agent may beforced to use only black and white shades instead of full colour. The ActualValue is the used value after any approximations have been applied.

5.4.2 Specified, computed, and actual values ofApplication Structure Attributes

WebCGM user agents are required to support the inheritance model ofApplication Structure (APS) Attributes defined in this section. Once a useragent has loaded a document and constructed a document tree, it must resolve,for every Application Structure in the tree, if an Attribute has a value (i.e.,no value is possible for some attributes).

Very similar to the CSS model, the final value of an APS Attribute is theresult of a four-step calculation: the value is determined throughspecification (the "Specified Value"), then resolved into a value that may beused for inheritance (the "Computed Value"), then converted into an absolutevalue if necessary (the "Used Value"), and finally transformed according to thelimitations of the local environment (the "Actual Value").

5.4.2.1 Specified Values ofApplication Structure Attributes

User agents must first assign a Specified Value to each APS Attribute basedon the following mechanisms (in order of precedence):

1. If the Attribute is assigned a value in the CGM document or assigned a new value via a DOM call or an XCF, use it.
2. Otherwise, if the Attribute is inherited (i.e., its definition includes "Inherited:yes") and the Application Structure is not the root of the document tree, use the Computed Value of the parent Application Structure.
3. Otherwise use the Attribute's Initial Value. The Initial Value of each Attribute is indicated in the Attribute's definition.

In the context of WebCGM inheritance, the root of the document tree is thePicture node. For the purposes of this inheritance model, the Picture root nodeis treated as if it were an Application Structure.

5.4.2.2 Computed Values ofApplication Structure Attributes

In this specification, Computed Values of Application Structure Attributes,with the exception of the 'inherit' value are identical to the SpecifiedValues. When the Specified Value is 'inherit', it must be replaced for theComputed Value as defined below in thesection oninheritance. The Computed Value exists even when the Attribute doesn'tapply (as defined by the 'Applies To' line in the Attribute's definition).

5.4.2.3 Used Values ofApplication Structure Attributes

In the CSS2 model from which the WebCGM model is derived, Computed Valuescan be relative to each other; for example a width could be set as apercentage, which is dependent on the containing block's width. The Used Valueis the result of taking the Computed Value and resolving these dependenciesinto a final absolute value used for the actual display. In this version ofWebCGM, there are no examples where Used Value differs from the Computed Value.This may change in a future version of the specification.

5.4.2.4 Actual Values ofApplication Structure Attributes

A Used Value is in principle the value used for rendering, but a user agentmay not be able to make use of the value in a given environment. For example, auser agent may only be able to render borders with integer pixel widths and maytherefore have to approximate the computed width, or the user agent may beforced to use only black and white shades instead of full colour. The ActualValue is the Used Value after any approximations have been applied. In thisversion of WebCGM, there are no examples where Actual Value differs from theUsed Value. This may change in a future version of the specification.

5.4.3 Inheritance

Some values are inherited by the children of an Application Structure in thedocument tree, as described above. Each Style Property and ApplicationStructure Attribute defines whether it is inherited or not. As a general rule,when inheritance occurs, Application Structures inherit Computed values ofStyle Properties and Application Structure Attributes (unless implicitly statedin the Property or Attribute definition).

5.4.3.1 The 'inherit'value

Application Structure Attributes and Style Properties may also have aSpecified Value of 'inherit'; which means that, for a given ApplicationStructure, the Property or Attribute takes the same Computed value of theApplication Structure's parent. The 'inherit' value can be used to strengtheninherited values, and it can also be used on Style Properties that are notnormally inherited. There are no examples of the latter in this version of WebCGM.

5.5 Basic data types

WebCGM consists of three components where data type definitions need to beconsidered: metafile instances, DOM, and XCF.

5.5.1 Metafile data types

WebCGM instances are binary files. Metafile data types and encodings arefully defined in theCGM:1999standard, together with chapters 3 and 6 of this WebCGM specification.

5.5.2 DOM data types

5.5.2.1 IDL types and binding types

Each interface of this DOM definition is normatively specified by a sectionof IDL code. The IDL uses basic data types such as unsigned short, boolean,long, etc. DOM applications are written in some programming language binding ofthe IDL, such as ECMAScript or Java. The only normatively specified binding forWebCGM DOM is theECMAScriptbinding.

The ECMAScript binding unambiguously associates ECMAScript language datatypes with the IDL data types, which provides all the data type informationneeded to write WebCGM DOM applications in ECMAscript.

Null returnvalue. WebCGM DOM attributes and method return values of typeWebCGMNode and WebCGMNodeList sometimes have to represent the case of no data,i.e., zero nodes. In the DOM functional specification of this chapter, the termnull is uniformly used to used to represent this case. In DOMbindings such as theECMAScriptbinding thenull return value maps naturally to anECMAScriptnull reserved keyword. (For example,myNode.childnodes==null evaluates to true, andmyPicture.getAppStructureById()==null evaluates to true.)

5.5.2.2 The WebCGMStringtype

One heavily used data type in the IDL definition is the WebCGMString, andsome of the DOM interfaces do specify substructure or sub-types for someWebCGMString attributes and parameters.

WebCGMString

A WebCGMString is a sequence of 16-bit units in WebCGM DOM.

IDL Definition

valuetype WebCGMString sequence<unsigned short>;

list-of-number  ::= number | number Wsp list-of-numberWsp             ::= (#x20 | #x9 | #xD | #xA)+

DelimitedString ::= ListX | ListXXListX           ::= '"'Name'"' | '"'Name'"' Wsp ListXListXX          ::= "'"Name"'" | "'"Name"'" Wsp ListXXWsp             ::= (#x20 | #x9 | #xD | #xA)+
Name            ::= (ValidChar)*

    a  c  e    b  d  f    0  0  1

    p' = M * p

    p' = Ma * Mt * p

    M = M3 * M2 * M1