Up to cover page | Back to WebCGM Concepts | On to XML Companion File

WebCGM 2.0 — WebCGM Intelligent Content

3 WebCGM Intelligent Content

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

3.1 Addressing objects

3.1.1 IRI fragment specification

3.1.1.1 Fragment definition

The IRI (Internationalized Resource Identifier) is how resources are identified on the Web. For example, a CGM file called web.cgm might have the following IRI:

http://example.org/web.cgm

Application structures and pictures within a WebCGM are addressed using the mechanism of the IRI fragment identifier. These WebCGM rules are derived from and are consistent with the Web protocols defined in IRI [RFC 3987] and URI (Uniform Resource Identifier) [RFC 3986].

An IRI which includes an IRI fragment identifier consists of an optional base IRI, followed by the separator character "#", followed by the IRI fragment identifier. For example, the following IRI can be used to specify the "wheelAssembly" object within web.cgm:

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

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

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

The IRI fragment syntax, as adopted by WebCGM, is based on concepts described in the XML Pointer Language (see XPointer Framework). The IRI fragment syntax is defined below. The formal grammar for the WebCGM fragment is given using a simple Extended Backus-Naur Form (EBNF) notation.

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

Note 2. WebCGM 1.0 described links using URI terminology, however implementations interpreted the WebCGM 1.0 language differently, and in fact some essentially supported IRIs (Internationalized Resource Identifiers). IRIs are a more generalized complement to Uniform Resource Identifiers ( URIs). An IRI is a sequence of characters from the Universal Character Set [Unicode40]. A URI is constructed from a much more restricted set of characters. All URIs are conformant IRIs. A mapping from IRIs to URIs is defined by the IRI specification, and this mapping is adapted to WebCGM below (3.1.1.4). IRIs can be converted to URIs if the WebCGM processor does not support IRIs directly. In this specification, the correct IRI terminology is used.

3.1.1.2 Fragment EBNF

The following notation is used:

    *  — 0 or more
    +  — 1 or more
    ?  — 0 or 1
    () — grouping
    |  — separates alternatives
    double quotes (") surround literals


webcgmfragment ::= picterm "." objterm | 
            picterm |
            objterm  |
            picid "." objid |
            objid | 
            xcfterm

picterm ::= pictureid | pictsequence

pictureid ::= "pictid("   picid   (","  behavior)? ")"

picid ::= (char)+

behavior ::=  "_blank" | "_self" | "_parent" | "_replace" | "_top" | target

target ::= (char)+

pictsequence ::= "pictseqno(" picseqno ("," behavior)? ")"

picseqno ::= (digit)+

digit ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" 

objterm ::= specialForm | normalForm

specialForm ::= "id(*,clearHighlight)"

normalForm ::= objectid | objectname

objectid ::= "id("   objid   ("," objbehavior)? ")"

objid ::= (char)+

objBehavior ::= navTerm | highlightTerm | navTerm "+" highlightTerm

navTerm ::= "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 Character Repertoire

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

1. Firstly, per the character set for type SF data. See section 6.3, T.14.5.
2. Secondly, the character repertoire for all of these productions is further restricted as defined in section 2.2 of XML 1.0, third 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 the name construct defined in section 2.3 of XML 1.0, third 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 valid objname; 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: as objid, plus must begin with [a-zA-Z], similarly to "Frame Target Name" of the HTML 4.01 Specification, upon which the set of WebCGM picture behaviors is based.
   • xcfurl - must be a valid IRI, according to the encoding 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 the WebCGM fragment specification. If any of these four significant characters is to appear in a valid id/name string within a fragment instance, then the fragment shall use the unabbreviated long form, which is the first of the six optional forms in the 'webcgmfragment' production of 3.1.1.2. In particular, all components of the long form shall be included, and none of the parts marked as optional in the EBNF may be omitted.

Note about picid: The character repertoire for picid occurrence in the fragment ("as objid") is more restrictive than the repertoire for the id parameter of the BEGIN PICTURE element itself (CGM data type SF, not further restricted). Any application which intends to use the picid field in the fragment must generate the picture ids to the more restrictive repertoire of the fragment. (See further discussion of picture selection keywords in fragments, section 3.1.2.1.)

3.1.1.4 Non-URI characters in IRIs

The URI character repertoire, as defined in RFC 3986, is comprised of the alphabetic and numeric characters of ASCII, plus a few punctuation marks. The character repertoires defined in 3.1.1.3, and allowed in IRIs, are much richer. The method for handling this disparity is described in this section.

An IRI in WebCGM content must be a URI reference as defined in RFC 3986, or must result in a URI reference after the 3-step escaping procedure is applied as described in RFC 3987 (IRI), section 3.1 ("Mapping of IRIs to URIs"), Step 2. The procedure is applied when a WebCGM processor (viewer, or any other WebCGM-interpreting process) passes the URI reference to a URI resolver.

This handling allows various degrees of " URI legal" (in the sense of RFC 3986-conforming) content to appear in WebCGM content, as shown in the examples at the end of this section. In the WebCGM context, WebCGM processors can practically determine when to apply the 3-step escaping procedure as follows: if an IRI in WebCGM content contains a character sequence that corresponds to a valid URI escaping sequence, i.e., a three-character "%HH" sequence, WebCGM processors shall consider that sequence to be a URI escaping sequence. Such a sequence may be passed directly to the URI resolver. (This is shown in the examples.)

This does still not guarantee that a URI will result that is valid according all applicable URI specifications. E.g., it could result in DNS-illegal characters in the domain name, if the input WebCGM content was badly formed its generator. Because it is impractical for any application to check that a value corresponds to a valid URI, this specification follows the lead of RFC 3986 in this matter and imposes no such conformance testing requirement on WebCGM applications. Although no URI conformance testing requirements or error handling are specified here, WebCGM processors should, of course, react gracefully to bad input.

3.1.1.5 Resolving relative IRIs for XCFs

The above fragment EBNF defines an xcfterm production whose 'xcfurl' parameter identifies an XML Companion File associated the WebCGM identified by the IRI. WebCGM viewers that support XCF must interpret the fragment, locate and load the XCF. The 'xcfurl' parameter is itself a IRI, and it can be absolute or relative. WebCGM viewers shall resolve a relative 'xcfurl' IRI relative to the IRI of the WebCGM instance with which the XML Companion File is a companion — i.e. relative to the WebCGM file referenced by the base part of the IRI containing the fragment — rather than relative to the file containing the IRI reference (e.g., an HTML file).

3.1.2 Fragment parameters

The following subsections describe in detail how fragment parameters are used to specify the picture behaviors and object behaviors of links containing the parameters. An informative summary of the rules is provided in the last subsection of this section (3.1.2.7).

3.1.2.1 Picture selection keywords

In a purely WebCGM 2.0 environment, the picture selection keywords are of limited utility, because WebCGM 2.0 allows only one picture per metafile. However, WebCGM 1.0 allowed multiple pictures per metafile. Therefore WebCGM 2.0 viewers might operate in legacy 1.0 or "mixed" 1.0/2.0 environments:

• WebCGM 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.0 metafiles might need to link to legacy WebCGM metafiles that are multi-picture;
• WebCGM 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 - The pictid keyword indicates that the picture to be viewed is identified by the id of the picture, which is the id parameter in the BEGIN PICTURE element. In the syntax, this is a required parameter of the picterm production, and there may be a second associated parameter, whose value is an optional picture behavior specification (see EBNF). If the metafile does not contain a picture with the specified picture id value, the first (and only) picture in the metafile is chosen.

pictseqno - The pictseqno keyword indicates that the identity of the picture to be viewed is by the sequence number of the picture in the metafile (see EBNF). In the syntax, this is a required parameter of the picterm production, and there may be a second associated parameter, whose value is an optional picture behavior specification. The picture sequence number shall be an integer greater than 0. If the specified picture sequence value exceeds the number of pictures in the metafile, the last picture is displayed.

3.1.2.2 Picture behaviors

Picture behaviors describe to the viewer how to display the remote resource of a hyperlink. Picture behaviors are based on the syntax and semantics of Frame Target Names defined in the HTML 4.01 Specification. The "picture behaviors" concept of WebCGM is used to collectively address CGM pictures and other Web resources. "Picture behaviors" 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 to be opened when the link is activated

The reserved names listed below describe the various picture behaviors. All other Picture Behavior values shall follow the naming convention of the presentation context in question. For example, if the presentation context is an HTML frame, then the naming convention for Frame Target Names in the HTML 4.01 Specification is followed — if not 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 Picture Behavior values, except for _replace, are based on Frame Target Names of HTML 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

The viewer shall replace the current CGM picture by the designated CGM picture 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 does not reload the resource. Applicable only to CGM-to-CGM links, 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 resource shall be displayed in the specified presentation context. If the presentation context already exists, it is re-used, replacing the existing content. If it does not exist, the viewer shall load the designated content (picture or document) in a new window with the specified name. Note that frame-target must be 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 parent object's relevant language. For example, if the parent language were HTML, then the link activation behavior would be defined by the HTML 4.01 Specification [HTML401].

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

<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 selection keywords

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 found in 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 no match is found in the picture, no object is selected.

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

3.1.2.4 Object behaviors

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

3.1.2.4.1 Enumeration of behaviors

WebCGM 2.0 contains twelve distinct object behaviors, eleven of which are generated by the fragment EBNF, and one of which is defined in the EBNF as a special-form object behavior fragment:

id(*,clearHighlight)

The default object behavior is zoom+newHighlight.

The next subsection defines the target rectangle of the navigation behaviors, depending on whether a single or multiple objects are selected by the object selection keyword. The highlight behaviors apply to all objects selected according to the object selection keyword.

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

The special-form behavior, id(*,clearHighlight), clears highlighting of any and all highlighted objects in the picture, without affecting the navigation state of the picture.

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

The following table enumerates the object behaviors available in WebCGM 2.0. The Navigation column indicates whether the viewer performs any navigation for the behavior, for the selected object(s). Highlighting indicates whether the viewer adjusts the highlighting of the selected object(s) in some way ("X") or not.

WebCGM 1.0 defined three object behaviors that WebCGM 2.0 deprecates — view_context, highlight, and highlight_all. WebCGM 2.0 viewers shall support these three object behaviors, and shall do so by mapping them to WebCGM 2.0 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 of target rectangle

If navigation to an object or group of objects is indicated, a target rectangle 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 multiple selected 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 Definition of behaviors

full

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

zoom

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

move

The viewer shall move (pan) the illustration such that the target 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 the selected object(s), first removing any highlighting that may exist on objects in the picture.

addHighlight

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

clearHighlight

See the definition of the special-form object behavior fragment in the enumeration of behaviors.

3.1.2.5 Zoom and pan

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

3.1.2.6 XML Companion File

The fragment syntax can be used to load and apply an XML Companion File (XCF) together with the WebCGM file. An interpreter that supports WebCGM DOM shall load the WebCGM file first. Then it shall load and apply the XML Companion File specified by the IRI (resolving a relative IRI if necessary). Finally it shall apply the XCF before the first display of the CGM.

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

3.1.2.7 Summary of behaviors

The following is informative summary and is intended to provide references to where the normative picture and object behaviors are defined.

• For links that contain an IRI with an IRI fragment and have a CGM object as the remote resource, object behaviors are specified as described in section 3.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) (see 3.1.2.2). Any picture behavior in an IRI fragment will be ignored by viewers (see 3.1.2.2).
• For links originating from a CGM resource, the picture behavior is to be expressed using the third parameter of the linkuri Application Structure Attribute (see 3.2.2.3). Note that encoding the picture behavior in the first parameter of the linkuri Application Structure Attribute is discouraged when targeting a CGM resource (see 3.2.2.3, "discouraged").
• For DOM script to CGM links the src attribute of the WebCGMMetafile interface specifies the IRI of the image. Specifying behavior as part of the IRI is prohibited (see 5.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 address objects 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 WebCGM fragment does not explicitly define the viewer behavior.

The following examples illustrate some of the ways the WebCGM fragment can be used. The examples describe how one might address a set of CGM files relating to various views of an engine which are stored on the example.org web site (http://example.org/webcgm/). The CGM files contain various views of an engine assembly - the top view, the front view, the right view, the left view, 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 the metafile name (without the ".cgm"), and with several identifiable objects — the oil pump, the cylinder head, the fan, the radiator, or the distributor. 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 and 3^rd parameters) in an object in a CGM file, this example retrieves engine_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 remains unchanged. The above expressions represent the preferred form (see 3.2.2.3) when the link is contained within CGM content. The following form is legal, but discouraged (may be removed from future 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 the IRI in an OBJECT element in HTML, this example displays the CGM inside a rectangle defined by the width and height parameters of the OBJECT tag, displaying the whole picture with 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 the IRI to target an object in a CGM file from an HTML file, this IRI (plus HTML attribute) retrieves the engine_iso.cgm CGM file from the example.org web site and 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 rectangular portion of the picture to display in the frame, else the fallback computation of a target 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 file from another CGM file, this linkuri (1^st and 3^rd parameters) retrieves the engine_front.cgm CGM file from the example.org web site and displays the picture in the metafile in the frame named "topframe", with a full-picture view. (See example 1, about alternate but discouraged forms.)

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 web site and displays the picture in the metafile. The view zooms to the target rectangle, which contains all objects with 'name' APS Attribute with value "cooling", and each such object is highlighted.

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 web site and displays the first (only) picture in the metafile. The view is zoomed to the computed target rectangle of the object with 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 the currently displayed picture, and will highlight the oil-pump-t object. Any existing highlighting of other objects in the picture is preserved.

3.2 Application Structure and APS Attribute descriptions

3.2.1 Application Structures

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

Although the picture body of a WebCGM picture is not itself an APS, the content rules of the picture body (picbody) are defined by this piece of EBNF (see the fragment syntax for definition of notation):

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

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

CGM:1999 requires that the Begin APS element of every Application Structure have a unique identifier parameter. The character repertoire of the APS id parameter in WebCGM content is identical to the repertoire defined for the objid fragment production in Section 3.1.1.3.

3.2.1.1 Grobject

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

Definition: The interactive region of an object is the effective geometric region for the purposes of all interactive cursor and mouse operations, such as picking and mouseover. By default, the drawn graphical primitives of the object define the interactive region. For filled-area primitives this includes: the edge, if edge visibility is 'on'; the interior, if the interior style is other than 'empty' or 'hollow'; and, the boundary, for interior style 'hollow'. For all graphical primitive types, drawn graphical primitives exclude any that are fully transparent (so a fully transparent object is equivalent to an empty object, for purposes of interactive region definition). If the object contains a 'region' APS Attribute, then that region area is the interactive region.

Content Model. The content of an APS of type 'grobject' is (see fragment syntax for definition 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 as other objects (APSs) that may be the target of a "pick" event, follow the rules of WebCGM DOM events. Those rules determine all aspects of the event processing, including the selection of the proper target object when there are multiple eligible candidates, and the selection of the proper handler to process the event. Viewers shall give visual feedback to the user that a successful pick has occurred, and an indication of the particular object (or region) which has been picked. The exact method of feedback is viewer dependent.

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

The CGM:1999 standard allows the definition of an APS to be continued in pieces which are disjoint in the file. If an APS occurs which has the same value of the 'id' parameter as an earlier APS occurrence, then that is construed as a continuation of the definition of that object. WebCGM 2.0 metafile instances shall not contain continued APS constructs.

3.2.1.2 Layer

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

Content Model. The content of an APS of type 'layer' is (see fragment 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 the presence of layers, their names and descriptions. Viewers shall provide functionality to selectively turn on and off the visibility of layers. Viewers may, but are not required to, provide additional functionality for the view manipulation and browsing of layers.

3.2.1.3 Para

Description. The application structure (APS) of type 'para' may be used to identify text ("paragraphs"). 'Para' together with 'content' can potentially enable applications to build text search functionality, especially in cases where the underlying graphical data does not comprise graphical text in a searchable form (e.g., the text has been rasterized, polygonized, or visually-single strings are fragmented into multiple smaller text elements). 'Para' APSs may contain any CGM graphical content allowed by this profile.

Content Model. The content of an APS of type 'para' is (see fragment syntax for definition 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, the viewer behavior of 'para' is identical to that of 'grobject' (3.2.1.1).

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

3.2.1.4 Subpara

Description. The application structure (APS) of type 'subpara', may be used to identify smaller fragments of text within APS of type 'para'. This enables, for example, the identification of the larger text block (the "paragraph") for searching purposes, and the tagging of smaller fragments as hotspots. 'Subpara' APSs may contain any CGM graphical content allowed by this profile, but may not contain nested APS. The APS attribute content rules of sub-para matches those of 'para'.

Content Model. The content of an APS of type 'subpara' is (see fragment syntax for definition 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. See 3.2.1.3, 'para'.

3.2.1.5 Grnode

Description. The application structure (APS) of type 'grnode' is meant to group basic graphical primitives only. For this reason, 'grnode' must contain the APS 'id' parameter required by CGM:1999 for all APS, but a 'grnode' cannot contain any APS attribute elements. The content of a 'grnode' is, however, not limited to graphical primitives. The allowed APS content of a 'grnode' is the same as for the 'grobject' Application Structure.

Even if 'visibility' and 'interactivity' are not allowed on the APS, the 'grnode' supports inheritance (i.e., it is possible to make a 'grnode' visible or 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 not interactive; i.e., it does not receive mouse events. If a mouse event is triggered on the geometry of a 'grnode', an ancestor node of type 'grobject' may respond to the event. Therefore, the content of a 'grnode' could effectively appear to be interactive, for example, if the 'grnode' were a direct child of a 'grobject'. See the Event interface for more information regarding mouse events.

3.2.1.6 About general metadata elements

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

3.2.2 Application Structure Attributes

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 event operations directed at the object, such as picking, mouseover, etc. This APS Attribute, if present, defines the interactive region of an object; else, the interactive region is defined by the geometry of the object.

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

Parameters. The data record is an SDR of one or more member pairs (i.e., 2*m members, m>=1). Each member-pair defines a simple region: the first member is 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 given point does not match the first, then the viewer closes the region with a straight line segment from the last to the first).

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

Viewer Behavior. See 3.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 to viewers of the initial view of an object, when the viewer has been directed to navigate to the graphical object which contains this attribute. A 'viewcontext' APS Attribute may be contained within an otherwise empty APS, in which case the APS provides only a viewport specification. At most one 'viewcontext' attribute may be present within a single APS.

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

Viewer Behavior. See 3.2.1.1.

3.2.2.3 Linkuri

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

Description. The 'linkuri' APS Attribute defines a IRI, to be associated with the object containing this attribute. When the object is selected by a graphical pick operation, and the WebCGM event model determines that hyperlink processing shall handle the event, then the viewer shall take necessary action to navigate the link. Multiple 'linkuri' attributes may be contained within a single APS. If the object contains more than one 'linkuri' attribute, the user shall be given a choice of which IRI to navigate.

Parameters. The data record is an SDR of one member, containing three strings (type SF, String Fixed). The first string is the link destination, a IRI, the second string (possibly null) is a Link Title parameter, and the third string (possibly null) is the Behavior parameter. Note that a null string is a zero-length string, and is not the same as an omitted parameter. The parameter must not be omitted.

The destination of a link is specified by a Internationalized Resource Identifier, or IRI. See section 3.1.1.4 for further discussion of this parameter. This specification does not constrain the syntax or semantics of a IRI in a 'linkuri' that identifies a resource that is not a CGM file (for example, an HTML or XML document).

The Behavior string defines picture behavior associated with the link. The values and meanings are as defined in 3.1.2.2. In cases 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 to CGM media types, and is the preferred method.

In the case that the IRI points to CGM media type, the picture behavior may be encoded within the optional fragment identifier in conjunction with the IRI structure, per section 3.1.1, " IRI fragment specification". This form is discouraged, and may be removed in a future edition of this profile. For specifying picture behavior, particular WebCGM 'linkuri' instances shall use either the Behavior string (preferred), or the picture behavior specification embedded in the fragment (discouraged), but not both.

3.2.2.4 Layername

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

Description. The 'layername' APS Attribute declares that the graphics associated with the 'layer' APS containing this attribute belong to the identified layer. The 'layername' is not required to be unique. If more than one 'layer' APS contains the same 'layername', then the occurrences following the first occurrence shall be construed as continuing the definition of the named 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 object belong to the null layer.

Viewer Behavior. See 3.2.1.2.

3.2.2.5 Layerdesc

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

Description. The 'layerdesc' APS Attribute provides optional descriptive text which is associated with the 'layer' APS in which it occurs. This may be used by viewers to facilitate required and optional layer manipulation functions, as described in 3.2.1.2. At most one 'layerdesc' attribute may be contained within a single 'layer' APS.

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

Viewer Behavior. See 3.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, to be associated with a graphical object, which viewers can display when the graphical cursor passes over the interactive region of the graphical object. Whether or not the screentip display actually occurs depends on how the WebCGM event model determines that mouse-over events should be handled. This APS Attribute may occur within any graphical object of WebCGM, specifically, within any APS of type 'grobject', 'para', and 'subpara', and there shall be at most one occurrence within 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, if one is defined for a graphical object, visible to the user when the cursor passes 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, that defines 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 in WebCGM content is identical to the repertoire defined for the objname fragment production in Section 3.1.1.3.

Viewer Behavior. The 'name' gives applications a way to associate common names with objects. The object can optionally be addressed by the value of the 'name' attribute. See 3.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 is text content in a 'para' APS and in a 'subpara' APS. It is provided as a basis on which applications can build text search (which is not further standardized in this version of WebCGM). Text that is apparent in a graphical display may not correspond to recognizable text strings in the metafile content itself. For example, the metafile content may draw the text with raster elements, or with filled strokes, or one character at a time in random order, etc.

A 'content' attribute on a 'para' APS should contain all of the rendered text of the 'para' APS, and a 'content' attribute on a 'subpara' APS should contain all of the rendered text of the 'subpara' APS. The 'content' APS Attribute may occur only within APS of type 'para' and 'subpara', and there shall 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.9 Visibility

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

Description. The 'visibility' attribute indicates if an object is visible or not. 'Visibility' applies to Application Structures (APS) of type 'layer', 'grobject', 'para' and 'subpara'. The value of 'visibility' is inherited 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 objects of type 'grnode', and inherits from objects of type 'grnode' to any descendents 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. A non-visible object is not displayed. A non-visible object behaves like a non-interactive object (i.e., it cannot be clicked or highlighted). This does not imply that the 'interactivity' attribute is changed to off, but simply that the user agent must not respond to mouse events.

3.2.2.10 Interactivity

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

Description. The 'interactivity' attribute indicates if an object may receive mouse events. 'Interactivity' applies to Application Structures (APS) of type 'layer', 'grobject', 'para' and 'subpara'. The value of 'interactivity' is inherited 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', 'interactivity' also inherits to objects of type 'grnode', and inherits from objects of type 'grnode' to any descendents 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, events for this object are disabled. This has the effect of disabling event handlers, cursor changes, highlighting, screentip and hyperlinking for the given node and its descendant. An object that is the target of a link always responds to highlighting, regardless of its 'interactivity' attribute value.

3.2.2.11 About general metadata elements

Description. This version and level of WebCGM do not allow additional APS Attribute elements to occur, other than as enumerated above. Private metadata may be associated with WebCGM objects by keeping the metadata outside of the CGM, and associating it with objects within the CGM. A means for binding external private metadata to WebCGM instances is defined in the section XML 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 of the CGM Version 4 functionality of WebCGM — the "Intelligence" content — using the formal specification technique of the XML DTD. It has been suggested that validating XML parsers could be adapted to perform content validation of WebCGM instances (either via modification of the readers, or via transformation of the intelligent content of the WebCGM instance).

<!-- To document the structure of the CGM Version 4      -->
<!-- content of WebCGM 2.0 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 a particular attribute can have at most one instance within a particular APS instance. This is not the case, and the normative rules are as specified in 3.2.2.1 through 3.2.2.10.

3.4 WebCGM and the object element

The only standard way to reference inline CGMs from HTML documents is through the object element, using the data attribute for the CGM file and the type attribute to specify the full Mime Type. The minimal element for adding CGM into a document would be:

Other HTML 4.01 attributes which may be used on the object tag include align, border, hspace, id, name and vspace. Use of align, border, hspace, and vspace is only permitted in Transitional HTML 4.01, not Strict HTML 4.01.

The attributes classid, codebase, declare, shapes, usemap, codetype, and archive are prohibited. Content which uses WebCGM shall not make direct reference to the code which may be used to display it.

The event-related attributes, ONCLICK,...,ONMOUSEOVER, are permitted but their effect is undefined in this version of WebCGM. Instead the WebCGM DOM offers an addEventListener method for adding event listeners on WebCGM documents

The attributes accesskey, alt, class, dir, lang, longdesc, standby, style, tabindex and title are permitted, but have no defined effect on CGM viewers and display of CGM pictures. They are used to improve accessibility, and may also affect the presentation of any alternative text content of the object element.

The object element can contain optional param elements, which allow the HTML to pass additional data to the target object. The following param elements are defined and permitted for WebCGM. Each param is presented as a name followed by permissible values (after the ":"), and description.

onload: <eventHandlerName(evt)>

The user supplies the name of an event handler that the viewer shall invoke upon the 'onload' event. This param element and handler allows for script writers to manipulate the WebCGM DOM at the point at which the user agent has fully parsed the object 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") the user zoom and pan controls of the viewer. It does not affect picture navigation by other means, such as object behaviors in IRI 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.

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 of viewport 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 a IRI fragment on the data attribute of the object element. In case of conflict, the viewport specification shall have precedence.

The viewport param element is deprecated and may be removed in a future version 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 by height and width specified on the object tag. These three parameters can be used to specify where and how to place the CGM within the window specified on the object 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'.

These param elements differ from the align attribute of object, which is used to specify where the object is placed in the document. This could be expressed using the param 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' with the different alignments.

Figure 5. Effects of fit

Figure 6. Effects of fill

Back to top of chapter