[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Fwd: 2nd Release fix
CGM Open members --
FYI...
A couple days ago, I was running some regression tests with the development
version of the pending MetaCheck 5.20 release, which will test WebCGM 1.0
Second Release (and ATA grex 2.6).
As the 2nd Rel changes were thought to be minor, and forward compatible,
imagine my surprise when all of the current static test suite failed the
2nd Release check!
Turns out, when we tightened up the character repertoire for 'picid', we
were thinking only of occurrences in the fragment for selection by id in
multi-picture metafiles (almost-deprecated usage). If the restricted
repertoire were applied to the id parameter of the BEGIN PICTURE element
itself ... problem with legacy stuff that will never enter into the
(almost-deprecated) select-by-id scheme.
As Second Release is to be published this week, we made a quick fix and
sent it to Chris Lilley. See attached.
Regards,
-Lofton.
>X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
>Date: Mon, 09 Jul 2001 15:16:55 -0600
>To: Chris Lilley <chris@w3.org>
>From: Lofton Henderson <lofton@rockynet.com>
>Subject: 2nd Release fix
>X-RCPT-TO: <lofton@rockynet.com>
>
>Chris,
>
>Here are the changes which you would apply to the 2nd Release text which
>you currently have in hand (attached are files with the changes applied):
>
>3.1.1.3, #3, 3rd bullet: Change "as objid." to "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)."
>
>Add new paragraph at end of 3.1.1.3: "Note that 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 intend
>to use multi-picture addressing by id must therefore generate the picture
>ids to the more restrictive repertoire of the fragment. See, however,
>comments at the end of 2.2.1 about deprecation of multi-picture metafiles
>in WebCGM application."
>
>For your convenience, attached are the full text for:
>
>** Errata document, with changes applied;
>** WebCGM Chapter 3, with changes applied.
>
>Thanks,
>-Lofton.
Title: WebCGM Intelligent Content
Up to cover page | Back to WebCGM Concepts | On to WebCGM Profile
The URI (Uniform Resource Identifier) is how resources are identified on the Internet. For example, a CGM file called web.cgm located on the CGM Open web site might have the following URI:
http://www.cgmopen.org/web.cgm
Pictures and objects (application structures) within a WebCGM are addressed using the mechanism of the URI fragment. These WebCGM rules are derived from and are consistent with the Web protocols defined in RFC-2396.
A URI fragment is the separator character " # " appended to the main part of the URI or the "base", followed by a string. The fragment string is usually specific only to a particular class of applications. This clause defines the WebCGM fragment which allows CGM viewers, web browsers, scripting engines, and other applications to address (point to) specific pictures and objects within pictures in CGM files.
The base URI is terminated by "#", and a fragment is appended which defines the picture, object, and the desired viewer behavior. The URI fragment syntax is based on concepts described in the XML Pointer Language(Xpointer). The URI fragment syntax is defined below. The formal grammar for the WebCGM fragment is given using a simple Extended Backus-Naur Form (EBNF) notation.
webcgmfragment ::= picterm "." objterm |
picterm |
objterm |
picid "." objid |
objid
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 ::= objectid | objectname
objectid ::= "id(" objid ("," objbehavior)? ")"
objid ::= (char)+
objbehavior ::= "view_context" | "highlight" | "highlight_all"
objectname ::= "name(" objname ("," objbehavior)? ")"
objname ::= (char)+
See next section for a definition of the "char" production.
The productions 'picid', 'target', 'objid', and 'objname' in the fragment grammar are represented by parameters in WebCGM of type non-graphical text (CGM type SF). Their character repertoire shall be restricted as follows.
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 five 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.
Comment about 'picid': note that 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 multi-picture addressing by id must therefore generate the picture ids to the more restrictive repertoire of the fragment. See, however, comments at the end of 2.2.1 about deprecation of multi-picture metafiles in WebCGM application.
The URI character repertoires, as define in the appropriate W3C specifications, basically comprise the alphabetic and numeric characters of ASCII, plus a few punctuations. The character repertoires defined in 3.1.1.3 are potentially much richer. The method for handling this disparity is as defined in section 4.2.2 of XML 1.0, second edition, REC-xml-20001006. That specification is adapted for WebCGM processors as follows.
A WebCGM processor shall interpret a non-ASCII character in a URI by representing the character in UTF-8 as one or more bytes, and then escaping these bytes with the URI escaping mechanism (i.e., by converting each byte to %HH, where HH is the hexadecimal notation of the byte value).
pictid - The pictid keyword indicates
that selection of the picture to be viewed is by the id of the
picture, which is the id parameter in the BEGIN PICTURE element.
The picture id value is the first, required parameter associated
with the keyword (see EBNF), and
there may be a second associated parameter, which is an optional
picture behavior specification. If the metafile does not contain a
picture with the specified picture id value, the first picture in
the metafile is chosen.
pictseqno - The pictseqno keyword
indicates that selection of the picture to be viewed is by the
sequence number of the picture in the metafile. "1" is the first
picture, "2" is the second picture, etc. An all-digit string
representing the picture sequence number value is the first,
required parameter associated with the keyword (see EBNF), 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 zero. If
the specified picture sequence value exceeds the number of pictures
in the metafile, the last picture is displayed.
Picture behaviors describe to the viewer how to display the picture, which is the target of a hyperlink. Picture behaviors are based on the syntax and semantics of " Frame Target Names" defined in the HTML 4.0 Specification.
The reserved names listed below describe the various picture behaviors. All other Picture Behavior values shall be valid Frame Target Names as described in the HTML 4.0 specification. Frame Target Names must begin with an alphabetic character (a-zA-Z).
In what follows, the following conventions apply:
The following Picture Behavior values, except for _replace, are defined per HTML 4.0:
If the picture behavior value is any valid name string other than the above reserved names, (it begins with an alphabetic character (a-zA-Z)), remove the existing content (picture or document) from the frame whose name matches the string and display the specified content in the specified frame. If no frame exists by the specified name, the viewer shall load the designated content (picture or document) in a new window with the specified name.
In the case that a link is HTML to CGM, the picture behavior should not be included in any fragment specification. Rather, the effect should be achieved with HTML TARGET attribute on the link specification in the HTML, per the specifications in the HTML 4.0 Recommendation. CGM viewers shall ignore picture behavior specifications in URI fragments which are part of links from non-CGM content.
The following table summarizes the rules for other link types, CGM-to-HTML and CGM-to-CGM:
| Picture behaviors and different source-to-destination types. | ||
|---|---|---|
|
CGM-to-HTML |
CGM-to-CGM | |
| _blank | The viewer shall load the designated document in a new, unnamed window. | The viewer shall load the designated picture in a new, unnamed window. |
| _self | The viewer shall load the document in the same frame as the one containing the CGM picture that refers to this target. This is the default for CGM-to-HTML links. | The viewer shall load the picture in the same frame as the one containing the CGM picture that refers to this target. |
| _parent | The viewer shall load the document into the immediate FRAMESET parent of the current frame in which the current picture is displayed. This value is equivalent to "_self" if the current frame has no parent. |
The viewer shall load the picture into the immediate
FRAMESET parent of the current frame in which the current
picture is displayed. This value is equivalent to "_self"
if the current frame has no parent. |
| _replace | Not applicable. Default to_self. | The viewer shall replace the current picture by the designated picture in the same rectangular area in the same frame or window as the picture which refers to this target. This is the default behavior for CGM-to-CGM links. |
| _top | The viewer shall load the document into the full, original window (thus canceling all other frames). This value is equivalent to _self if the current frame has no parent. | The viewer shall load the picture into the full, original window (thus canceling all other frames). This value is equivalent to _self if the current frame has no parent. |
| target | The viewer shall load the document into the frame identified by "target". If no matching frame can be found, the viewer shall load the designated content document in a new window with the specified name. | The viewer shall load the picture into the frame identified by "target". If no matching frame can be found, the viewer shall load the designated content document in a new window with the specified name. |
Note: Link interactions between CGM and non-CGM mime types other than HTML follow the same rules as CGM and HTML interactions.
Figures 3 and 4 below give examples of _self and _replace.
Figure 3. Example of _self
Figure 4. Example of _replace
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. The first object in the picture which contains
a 'name' attribute with a matching value is selected. If no match is
found in the picture, no grobject is selected. If more than one
match is found in the picture the 'highlight_all' behavior can be
used to highlight all selected objects.
view_context - If a 'viewcontext' APS attribute exists
for the object APS, display only the rectangular region of the
picture defined by the 'viewcontext' APS attribute, and highlight the
object. If no 'viewcontext' APS attribute exists in the object, the
highlight behavior shall be implemented. The "view_context" object
behavior is the default behavior. (See
3.2.1.1).
highlight - highlight the first object selected and
ignore the 'viewcontext' attribute, if present. The resulting view is
a full-picture view, not a zoomed view.
highlight_all - highlight all objects selected. The
resulting view is a full-picture view, not a zoomed view.
In addition to being able to meet the zooming requirements imposed by the object behavior specifications, and those zooming requirements imposed by support of the OBJECT tags paramenters, 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.
The WebCGM fragment in its most verbose form provides the means to address objects in single or multiple picture metafiles and tell 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 the CGM file "engine.cgm" which is stored on the CGM Open website (http://www.cgmopen.org/webcgm/). The CGM file contains various pictures of an engine assembly - the top view, the front view, the right view, the left view, and the isometric view. The pictures are ordered sequentially in the CGM file and identified as follows:
Picture 1: picid="top"
Picture 2: picid="front"
Picture 3: picid="right"
Picture 4: picid="left"
Picture 5: picid="iso"
Each picture in the CGM file contains 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 picture are as follows:
Picture 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'
Picture 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'
Picture 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'
Picture 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'
Picture 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'
http://cgmopen.org/webcgm/engine.cgm#pictid(top,_blank).id(cyl-hd-t,highlight)
When used as the value of the URI attribute in an object in a CGM file, this URI retrieves engine.cgm CGM file from the cgmopen.org web site and displays the picture named "top" in a new window, highlighting the object with an id of "cyl-hd-t". The existing display remains. The entire picture is displayed, regardless of the presence of a 'viewcontext' APS for the object "cyl-hd-t". Note that inclusion of the picture behavior, "_blank", in the URI fragment is not the preferred formulation for this link/behavior combination (see 3.2.2.3). The preferred form would place the string "_blank" into the 3rd parameter of the 'linkuri' APS attribute, and the first parameter would be:
http://cgmopen.org/webcgm/engine.cgm#pictid(top).id(cyl-hd-t,highlight)
http://cgmopen.org/webcgm/engine.cgm#pictid(top).id(oil-pump-t,highlight)
When used as the URL 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 of "top" with the pump highlighted. Since "top" is the first picture in the file, if we had used the name "top-view" the visual result would have been the same, since "top" is the first picture in the file.
http://cgmopen.org/webcgm/engine.cgm#pictseqno(5,topframe).id(dist-i,view_context)
When used as the value of the URI attribute in a object in a CGM file, this URI retrieves the engine.cgm CGM file from the cgmopen.org web site and displays the fifth 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. Note, as in example 1, that inclusion of the picture behavior, a target frame named "topframe", in the URI fragment is not the preferred formulation for this link/behavior combination (see 3.2.2.3). The preferred form would place the string "topframe" into the 3rd parameter of the 'linkuri' APS attribute, and the first parameter would be:
http://cgmopen.org/webcgm/engine.cgm#pictseqno(5).id(dist-i,view_context)
http://cgmopen.org/engine.cgm#picseqno(2,topframe)
When used as the value of the URI attribute in a object in a CGM file, this URI retrieves the engine.cgm CGM file from the cgmopen.org web site and displays the second picture in the metafile in the frame named "topframe" Note, as in example 1 and 3, that inclusion of the picture behavior, a target frame named "topframe", in the URI fragment is not the preferred formulation for this link/behavior combination (see 3.2.2.3). The preferred form would place the string "topframe" into the 3rd parameter of the 'linkuri' APS attribute, and the first parameter would be:
http://cgmopen.org/webcgm/engine.cgm#pictseqno(2)
http://cgmopen.org/webcgm/engine.cgm#name(cooling)
This example retrieves the engine.cgm cgm file from the cgmopen.org web site and displays the first (default) picture in the metafile. The first object containing a 'name' attribute with value "cooling" is highlighted and the 'viewcontext' APS attribute, if it exists, is used to define the rectangular area of the picture to display.
http://cgmopen.org/webcgm/engine.cgm#fan-t
This example retrieves the engine.cgm cgm file from the cgmopen.org web site and displays the first (default) picture in the metafile. The object with id "fan-t" is highlighted and the 'viewcontext' APS attribute of the object, if it exists, is used to define the rectangular area of the picture to display.
#id(oil-pump-t)
This example will highlight the object "oil-pump-t" in the currently displayed picture and the 'viewcontext' APS attribute, if it exists for the object "oil-pump-t", is used to define the rectangular area of the picture to display. The address fragment could be shortened even further to "#oil-pump-t"
Often, applications will display several pictures in a single HTML page. The only way to address the cgm viewer instance that is responsible for the display of a particular picture is via the "object" tag defined in HTML 4.0. The CGM defined by the object tag can be uniquely addressed using the <name> parameter of the object tag. However, the specific syntax for addressing a specific CGM in an HTML page is not standardized.
The Document Object Model (DOM) is currently under development. This work, when completed, is expected to provide a standard basis for addressing this problem.
WebCGM has four APS types: layer, grobject, para, and subpara. This document uses the term "object" to refer to an APS of type 'grobject', 'para', and 'subpara'.
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 and END APS elements (if any), or by the spatial region associated with the 'region' APS Attribute (if present). 'Grobject' APSs may contain any CGM graphical content allowed by this profile, and may contain other APS and APS attribute content as defined in section 3.3 (the complete, normative WebCGM content model).
Viewer Behavior. A 'grobject' APS may be selected by the user ("pick"). The viewer shall decide about the pick selection in the following manner:
It is possible that a user selection ("pick") of a object in a displayed WebCGM picture may not have a single unambiguous result - the cursor location may reside within the geometric extent or 'region' of more than one APS. In such a case, the pick priority is as follows:
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 default behavior of the viewer shall be as follows:
The case of default object behavior and no 'viewcontext' APS attribute requires a full-picture view, not a zoomed view. Some legacy intelligent graphics content, as well as some closely related IG profiles, have specified that this case requires a zoomed view. Viewers should have an operating mode to select zoomed view for these default cases. The next functional edition of WebCGM will have explicit controls for this viewer behavior.
Caveat: the CGM 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 occurrance, then that is construed as a continuation of the definition of that object. This has not been prohibited in the WebCGM 1.0 profile. However, it is considered to be problematic, separating the logical structure from the file structure, and allowing non-hierarchical constructs in the latter. Prohibiting continued APS in the next functional Edition of WebCGM is under active discussion, and is considered likely.
Description. The 'layer' APS declares that the graphical content within this APS and any valid nested APS ('grobject' and 'para', but not 'layer') belong to the layer identified by the contained 'layername' APS attribute. Each 'layer' APS shall contain exactly one 'layername' APS attribute and also may contain one 'layerdesc' APS attribute.
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. Viewer may, but are not required to, provide additional functionality for the view manipulation and browsing of layers.
Description. The application structure (APS) of type 'para', may be used to identify text ("paragraphs"). In the case that the underlying graphic does not represent graphical text in a searchable form (e.g., the text has been rasterized, polygonized, broken into small units, or pieces of a single string occur in awkward order), 'para' together with 'content' can potentially enable text search functionality. 'Para' APSs may contain any CGM graphical content allowed by this profile, and may contain other APS and APS attribute 'content' as defined in section 3.3 (the complete, normative WebCGM content model).
Viewer Behavior. The WebCGM prescription for priority of text search matching is: 'para' with matching 'content' (1st priority match); 'para' without 'content' but with recognizable single-element RESTRICTED TEXT match (2nd priority match); or, single-element RESTRICTED TEXT match, outside of any 'para' (3rd priority match). Further details of behavior of viewers with respect to identifying matches or communicating the identity of matches is not specified in WebCGM 1.0.
In other respects, e.g., picking and link navigation, the viewer behavior of 'para' is identical to that of 'grobject'. See 3.2.1.1.
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, may not contain nested APS, and may contain APS attribute 'content' as defined in section 3.3. The APS attribute content rules of sub-para matches those of 'para'.
Viewer Behavior. See 3.2.1.3, 'para'.
Description. This version and level of WebCGM do not allow additional APS elements to occur, other than 'grobject', 'layer', 'para', and 'subpara'. Private metadata may be associated with WebCGM objects by keeping the metadata outside of the CGM, and associating it with objects within the CGM. The methods, structures, and results of such private intelligent graphics architectures are not specified by WebCGM 1.0, and are outside the scope of standardized interchange under WebCGM 1.0.
Description. The 'region' APS Attribute provides an optional spatial region, associated with a graphical object, which assumes precedence for user picking operations directed at the object. Simple regions of type rectangle, ellipse, polygon, and continuous 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 a 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:
The second member is type VDC and contains:
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.
Description. The 'viewcontext' APS Attribute provides 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 a SDR of 1 member of type VDC defining two corner points of a rectangle.
Viewer Behavior. See 3.2.1.1.
Description. The 'linkuri' APS Attribute defines a URI, to be associated with the object containing this attribute. When the object is selected by a graphical pick operation, then the viewer shall take necessary action to navigate the link. Multiple 'linkuri' attributes may be contained within a single APS.
Parameters. The data record is a SDR of one member, containing three strings (type SF, String Fixed). The first string is the link destination, a URI, the second string (possibly null) is a Link Title parameter, and the third string is (possibly null) the Behavior parameter. Note that a null string is a zero-length string, and is not the same as an omitted parameter.
The destination of a link is specified by a Uniform Resource Identifier, or URI. Any valid URL under the specifications of RFC-2396 is a valid value of this parameter. This specification does not constrain the syntax or semantics of a URI 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 3rd 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 URI points to CGM media type, the picture behavior may be encoded within the optional fragment identifier in conjunction with the URI structure, per section 3.1.1, "Addressing Pictures and Objects". This form is deprecated, 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, but not both.
Description. The 'layername' APS Attribute declares that the graphics associated with the 'layer' APS containing this attribute belong to the identified layer. The 'layername' need not 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. At most one 'layername' attribute may be present within a single 'layer' APS.
Note: as a consequence of ISO CGM Defect Resolution 8632-1/064, the definition of any application structure can be continued by the occurrence of a disjoint APS (i.e., a separate BeginAPS-content-EndAPS group) with the same APS id parameter value. Therefore, the definition of a given layer can be continued by repeating the value of the 'layername' APS attribute in a disjoint APS, either with different APS id value, or with the same APS id value. However, it is not permitted for a subsequent disjoint APS to have the same APS id value as a previous APS, but with a different value of the 'layername' APS attribute.
Parameters. The data record is a 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.
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 a SDR of one member, containing one string (type SF, String Fixed).
Viewer Behavior. See 3.2.1.2.
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 graphical object. 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 a 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.
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. This is the same as the Name ("common name") APS Attribute of ATA Grexchange 2.4. Multiple 'name' attributes may be contained within a single APS.
Parameters. The data record is a SDR of one member, containing one string (type SF, String Fixed).
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.
Description. The 'content' APS Attribute provides a means to declare what is the first priority searchable text content of a 'para' APS. The 'content' APS Attribute may occur only within APS of type 'para' and 'sub-para', and there shall be at most one occurrence within any such APS.
Parameters. The data record is a SDR of one member, containing one string (type SF, String Fixed).
Viewer Behavior. See the description under the 'para' APS, 3.2.1.3.
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. The methods, structures, and results of such private intelligent graphics architectures are not specified by WebCGM 1.0, and are outside the scope of standardized interchange under WebCGM 1.0.
This is the formal specification of the content model of the CGM Version 4 functionality of WebCGM - the "Intelligence" content. XML has been chosen as the specification language, as validating parsers are widely available which could be adapted to perform content validation checking against WebCGM instances (either via modification of the readers, or via transformation of the intelligent content of 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 CGM APS element. --> <!ELEMENT picbody (layer+ | (grobject | para | gdata)*) > <!ELEMENT layer (grobject | para | gdata)+ > <!ATTLIST layer id ID #REQUIRED layername CDATA #REQUIRED layerdesc CDATA #IMPLIED > <!ELEMENT grobject (grobject | para | gdata)* > <!ATTLIST grobject id ID #REQUIRED region CDATA #IMPLIED viewcontext CDATA #IMPLIED linkuri CDATA #IMPLIED screentip CDATA #IMPLIED name CDATA #IMPLIED > <!ELEMENT para (subpara | gdata)* > <!ATTLIST para id ID #REQUIRED region CDATA #IMPLIED viewcontext CDATA #IMPLIED linkuri CDATA #IMPLIED screentip CDATA #IMPLIED content CDATA #IMPLIED > <!ELEMENT subpara (gdata)* > <!ATTLIST subpara id ID #REQUIRED region CDATA #IMPLIED viewcontext CDATA #IMPLIED linkuri CDATA #IMPLIED screentip CDATA #IMPLIED content CDATA #IMPLIED > <!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.8.
The only standard way to reference in-line CGMs from HTML documents is through the OBJECT tag, using the DATA attribute for the CGM file and the TYPE attribute to specify the full Mime Type. The minimal tag for adding CGM into a document would be:
<OBJECT DATA="xxx.cgm"
TYPE="image/cgm;Version=4;ProfileId=WebCGM"; WIDTH=200;
HEIGHT=100>
Other HTML 4.0 attributes which may be used in 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.0, not Strict HTML 4.0.
The attributes CLASSID, CODEBASE, DECLARE, SHAPES, USEMAP, CODETYPE, and ARCHIVE are prohibited. Content with 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, Edition 1.0, of WebCGM. Mouse-related events occurring within the area of the WebCGM picture will be handled by the WebCGM viewer, which need not expose these events.
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 OBJECT. The following PARAMs are defined and permitted for WebCGM. Each PARAM is presented as a name, and permissible values.
<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. Example of Fit
Figure 6. Example of Fill
Up to cover page | Back to WebCGM Concepts | On to WebCGM Profile
|
Editing Directives 22 June 2001 IntroductionHerein are editing directives to produce WebCGM 1.0 Second Release. These include a set of editorial corrections and clarifications that were processed and approved by CGM Open in 1999 and 2000. Also included are a set of corrections and clarifications that have been discussed and approved by the CGM Open Technical committee at its December meeting (and subsequent teleconferences). Finally, additional directives came from the process of building the first WebCGM test suite and upgrading a WebCGM validator in 2001. Editing Directives - IntroCorrection, 1.1Change 1992 reference to 1999 Correction, 1.2Change reference "CGM:1992 Amendment 2:" to "CGM :1999 Clause 9 "Profiles and conformance"" and change "of the amendment" to "of CGM:1999 Annex I.1, Proforma tables" Correction, 1.4Delete references to "grex24" since this is no longer the ATA naming convention Clarification, 1.5Add new bullet to the end of the bullet list: "Work is in progress on a WebCGM conformance test suite, and is anticipated to be available from CGM Open during the third quarter of 2001." Clarification, 1.5Add new paragraph at end: "WebCGM contains both static graphics functionality and dynamic behaviors functionality. Viewer conformance to the static graphics functionality can be measured for any kind of WebCGM viewer. Full viewer conformance to the dynamic behaviors specifications can only be measured in an environment of HTML-based documents and Web browsers. Therefore, full conformance of a viewer to all specifications in WebCGM 1.0 can only be measured for a WebCGM browser plugin (or equivalent architecture)." Correction, 1.6Change "CGM:1992 AM1, Rules for Profiles" to "CGM:1999, Clause 9, Profiles and conformance" Clarification, 1.6Change "Editions" to "Editions and Releases" in the title. Add a new final paragraph: "This release is Second Release of WebCGM 1.0. WebCGM 1.0 Second Release is a maintenance and defect correcting release of the functional Edition 1.0." Correction, 1.7Change reference to "CGM Amd.2, Rules for Profiles" to "CGM:1999 Annex I" Correction, 1.8.1Change the first occurrence of 1992 to 1999. Insert a "space" in "Part1". Delete the line "Part 2: Character Encoding". Delete the paragraph dealing with republication of the CGM standard. Delete the references to Amd 1 and Amd2 (and all of their Parts). Update, 1.8.1Replace RFC's 1739 and 1808 with "RFC-2396, Uniform Resource Identifiers (URI): Generic Syntax, URL: http:www.ietf.org/rfc/rfc2396.txt" Editorial, 1.8.2Add "www." to the Web address of CGM Open. Editing Directives - ConceptsCorrection, 2.1Change 1992 to 1999 Editorial, 2.2.1In the 5th paragraph delete the "|" at the end of the paragraph Clarification, 2.2.1Add new paragraph at the end of the section: "Note. There is technical discussion of limiting WebCGM instances, in a future functional Edition, to one picture per metafile, symbol library metafiles excepted. Therefore applications should give careful consideration before adopting a multi-picture metafile design." Correction, 2.3.1Change SGML to XML and remove words about tabular form Editorial, 2.3.4Change the first word of each bulleted item to be all lowercase without apostrophe quoting. 5th bullet: remove the ":". Change layerdescription to layerdesc Editorial, 2.3.5Change reference of Figure 1 to figure 2 Editorial, 2.3.5There are three errors: change "gprm" to "cgmprim" in the 2nd to last sentence; in the figure, change "viewconpxt" to "viewcontext"; and, the figure lacks a label and title (see next item), and in any case, it is not "Figure 1" ("Figure 1" is already used in section 2.1). Correction, 2.3.5 Chart 1Add 'rep' above the layer box to match XML content model in section 3. Correction, 2.3.5 Chart 2Change viewcontxt to viewcontext. Correction, 2.3.5 Chart 3Change viewcontxt to viewcontext. Correction, 2.3.6Replace reference to 1738 with 2396. Correction, 2.3.6Replace 3 occurrences of 'linkURI' with 'linkuri'. Change 'LinkTitle' parameter to Link Title parameter. Correction, 2.5.1Change 1992 to 1999 in first paragraph, second paragraph under "Smooth curves bullet", and under "Raster capabilities bullet", in the third paragraph, and in the fourth paragraph main body and under second bullet Correction, 2.5.2Change 1992 to 1999 in second paragraph Correction, 2.5.3Change 1992 to 1999 in first paragraph. Change "in registration" to "registered". Change 1992 to 1999 in second paragraph. Change [grex24] to ATA GREXCHANGE. Correction, 2.5.4Change 1992 to 1999 in second bullet of first paragraph. Second paragraph: Remove "Symbol" from default character sets. Change [grexch] to ATA GREXCHANGE. Editing Directives - Intelligent ContentEditorial, Figure NumbersIn clause 3, the figure numbers are 3.1, 3.2, 3.3, and 3.4. In clause 2, the first figure is labeled "Figure 1". The style in clause 2 matches the ISO style (and there doesn't appear to be an over-riding W3C style). Therefore it should be used throughout -the figure in 2.3.5 should be "Figure 2", and the four figures in clause 3 should be "Figure 3",..., "Figure 6". Correction, Character case of viewcontext.Throughout clause 3, change all occurrrences of ViewContext (or similar variants) to match the correct required syntax, per the specification of 3.3, which is all lowercase. Occurrences in descriptive text should be apostrophe-quoted, in the style used for WebCGM 1.0 references to APS attribute types. Correction, Character case of linkURI.Throughout clause 3, change all occurrrences of LinkURI (or similar variants) to match the correct required syntax, per the specification of 3.3, which is all lowercase. Occurrences in descriptive text should be apostrophe-quoted, in the style used for WebCGM 1.0 references to APS attribute types. Correction, Character case of subpara.Throughout clause 3, change all occurrrences of SubPara (or similar variants) to match the correct required syntax, per the specification of 3.3, which is all lowercase. Occurrences in descriptive text should be apostrophe-quoted, in the style used for WebCGM 1.0 references to APS attribute types. Correction, Character case of layername.Throughout clause 3, change all occurrrences of LayerName (or similar variants) to match the correct required syntax, per the specification of 3.3, which is all lowercase. Occurrences in descriptive text should be apostrophe-quoted, in the style used for WebCGM 1.0 references to APS attribute types. Correction, Character case of layerdescription.Throughout clause 3, change all occurrrences of LayerDescription or LayerDesc (or similar variants) to match the correct required syntax, per the specification of 3.3, which is all lowercase. Also, occurrences of 'layerdescription' are incorrect and should be 'layerdesc'. Occurrences in descriptive text should be apostrophe-quoted, in the style used for WebCGM 1.0 references to APS attribute types. Correction, Character case of screentip.Throughout clause 3, change all occurrrences of ScreenTip (or similar variants) to match the correct required syntax, per the specification of 3.3, which is all lowercase. Occurrences in descriptive text should be apostrophe-quoted, in the style used for WebCGM 1.0 references to APS attribute types. Editorial, "should" versus "shall"Imprecise language has been used in many places, for conformance requirements. Specifically, "should" has been used where "shall" is required. These should all be changed: 3.1.2.2, 2nd pgph: "Viewers should...". It should be "Viewers shall..." 3.1.2.2: 7 total occurrences, all should be changed. 3.1.2.4, 1st pgph: 1 occurrence, change it. 3.1.3.1, 1st pgph: 1 occurrence, change it. 3.2.1.1: 6 occurrences, all should be changed. 3.2.2.3: 1st paragraph, change single occurrence. 3.2.2.3: 4th pgph, change "should normally" to "shall". 3.4: 4 occurrences, change all of them (note related comment below about sentence containing 1st). Correction, 3.1.1Divide into four subsections. 3.1.1.1 should be "Fragment Definition" and include the existing paragraphs of prose. 3.1.1.2 should contain the EBNF and be "Fragment EBNF". 3.1.1.3 should be right after the EBNF and should be "Fragment Character Repertoire"; 3.1.1.4 should be "Non-ASCII Characters in URIs". In the EBNF, change each occurrence of (namechar)+ to (char)+. Delete the production for namechar and the rest of the lines in the grammar after it. In the new 3.1.1.3 put: "The productions 'picid', 'target', 'objid', and 'objname' in the fragment grammar are represented by parameters in WebCGM of type non-graphical text (CGM type SF). Their character repertoire shall be restricted as follows.
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 five 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. Comment about 'picid': note that 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 multi-picture addressing by id must therefore generate the picture ids to the more restrictive repertoire of the fragment. See, however, comments at the end of 2.2.1 about deprecation of multi-picture metafiles in WebCGM application." In the new 3.1.1.4 put: The URI character repertoires, as defined in the appropriate W3C specifications, basically comprise the alphabetic and numeric characters of ASCII, plus a few punctuations. The character repertoires defined in 3.1.1.3 are potentially much richer. The method for handling this disparity is as defined in section 4.2.2 of XML 1.0, first edition, REC-xml-20001006. That specification is adapted for WebCGM processors as follows. A WebCGM processor shall handle a non-ASCII character in a URI by representing the character in UTF-8 as one or more bytes, and then escaping these bytes with the URI escaping mechanism (i.e., by converting each byte to %HH, where HH is the hexadecimal notation of the byte value). Editorial, 3.1.1In the EBNF production for "behavior", each of the reserved keyword options (_blank through _top, but *not* target), should be quoted, e.g., "_blank". Correction, 3.1.1The production, picseqno ::= [0-9]+ should be (digits)+ instead. Include the definition of digits. Correction, 3.1.1.1Replace references to 1738 and 1808 with 2396. Clarification, 3.1.2.1Replace all of 3.1.2.1 with the following:
Correction, 3.1.2.2Replace all of 3.1.2.2 with the following: Picture behaviors describe to the viewer how to display the picture, which is the target of a hyperlink. Picture behaviors are based on the syntax and semantics of "Frame Target Names" defined in the HTML 4.0 Specification. The reserved names listed below describe the various picture behaviors. All other Picture Behavior values shall be valid Frame Target Names as described in the HTML 4.0 specification. Frame Target Names must begin with an alphabetic character (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 or a link, and is either a picture (CGM) or a document (HTML), depending upon the formulation of the particular link. The following Picture Behavior values, except for _replace, are defined per HTML 4.0: _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 in the same rectangular area in the same frame as the picture which refers to this target. Applicable only to CGM-to-CGM links (i.e., this is not defined in HTML 4.0), 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 any valid name string other than the above reserved names, (it begins with an alphabetic character (a-zA-Z)), remove the existing content (picture or document) from the frame whose name matches the string and display the specified content in the specified frame. If no frame exists by the specified name, the viewer shall load the designated content (picture or document) in a new window with the specified name. In the case that a link is HTML to CGM, the picture behavior should not be included in any fragment specification. Rather, the effect should be achieved with HTML TARGET attribute on the link specification in the HTML, per the specifications in the HTML 4.0 Recommendation. CGM viewers shall ignore picture behavior specifications in URI fragments which are part of links from non-CGM content. The following table summarizes the rules for other link types, CGM-to-HTML and CGM-to-CGM:
Note: Link interactions between CGM and non-CGM mime types other than HTML follow the same rules as CGM and HTML interactions. Figures 3 and 4 below give examples of _self and _replace. Editorial, 3.1.2.2Figure 3.2, the picture in "Example of _replace", is identical to that in Figure 3.1, "Example of _self". Change the LinkURI in Figure 3.2 to: "B.cgm#pictseqno(1,_replace)". Editorial, 3.1.2.4Replace the view_context object behavior with: "If a 'viewcontext' APS attribute exists for the object APS, display only the rectangular region of the picture defined by the 'viewcontext' APS attribute, and hightlight the object. If no 'viewcontext' APS attribute exists in the object, the highlight behavior shall be implmented. The "view_context" object behavior is the default object behavior. (See also section 3.2.1.1)." Correction, 3.1.2.5 - New sectionAdd a new section (3.1.2.5) with the title Zoom and pan. The content of this section is: "In addition to being able to meet the zooming requirements imposed by the object behavior specifications, and those zooming requirements imposed by support of the OBJECT tag parameters, viewers which operate in an ineraction-capable environment shall have zoom and pan controls available to the user. The exact methods and user interface for zoom and pan selection and manipulation are viewer dependent". Correction, 3.1.3.2In the 1st line of the example, change "$$new_window" to "_blank". Replace the paragraph with: When used as the value of the URI attribute in a object in a CGM file, this URI retrieves engine.cgm CGM file from the cgmopen.org web site and displays the picture named "top" in a new window, highlighting the object with an id of "cyl-hd-t". The existing display remains. The entire picture is displayed, regardless of the existence of a view context for the object "cyl-hd-t". Note that inclusion of the picture behavior, "_blank", in the URI fragment is not the preferred formulation for this link/behavior combination (see 3.2.2.3). The preferred form would place the string "_blank" into the 3rd parameter of the linkURI APS attribute, and the first parameter would be: http://cgmopen.org/webcgm/engine.cgm#pictid(top).id(cyl-hd-t,highlight) Correction, 3.1.3.3The first sentence of the description should be changed as follows: "When used as the URL 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 of "top" with the pump highlighted. Correction, 3.1.3.4Replace the paragraph with: When used as the value of the URI attribute in a object in a CGM file, this URI retrieves the engine.cgm CGM file from the cgmopen.org web site and displays the fifth picture in the metafile in the frame named "topframe", highlighting the object with an id of "dist-i". The view context (if present) attribute for the object "dist-i" is used to determine the rectangular portion of the picture to display in the frame. Note, as in example 1, that inclusion of the picture behavior, a target frame named "topframe", in the URI fragment is not the preferred formulation for this link/behavior combination (see 3.2.2.3). The preferred form would place the string "topframe" into the 3rd parameter of the linkURI APS attribute, and the first parameter would be: http://cgmopen.org/webcgm/engine.cgm#pictseqno(5).id(dist-i,view_context) Correction, 3.1.3.5Replace the paragraph with: When used as the value of the URI attribute in a object in a CGM file, this URI retrieves the engine.cgm CGM file from the cgmopen.org web site and displays the second picture in the metafile in the frame named "topframe" Note, as in example 1 and 3, that inclusion of the picture behavior, a target frame named "topframe", in the URI fragment is not the preferred formulation for this link/behavior combination (see 3.2.2.3). The preferred form would place the string "topframe" into the 3rd parameter of the linkURI APS attribute, and the first parameter would be: http://cgmopen.org/webcgm/engine.cgm#pictseqno(2) Clarification, 3.2.1.1Add a new paragraph at the end: "Caveat: the CGM 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. This has not been prohibited in the WebCGM 1.0 profile. However, it is considered to be problematic, separating the logical structure from the file structure, and allowing non-hierarchical constructs in the latter. Prohibiting continued APS in the next functional Edition of WebCGM is under active discussion, and is considered likely. Clarification, 3.2.1.1There is an ambiguity between the description of 3.1.2.4, Object Behaviors, and the description in the last paragraph ("If a APS is the target of a link...") of 3.2.1.1. Specifically, the paragraph, "If the object contains neither a view context nor a region attribute, the viewer should move the object into view and indicate visually that the graphical primitives of the grobject are the target of the link. The manner in which the viewer creates the new display is viewer dependent." could be interpreted as suggesting a zoomed view of the object. It has been resolved during the Granada interoperability demo that this is not the case. Therefore, add to the 3rd bullet at the end of 3.2.1.1, and to the descriptions of 'highlight' and 'highlight_all' in 3.1.2.4, the sentence: "The resulting view is a full-picture view, not a zoomed view." Editorial, 3.2.1.1Change "a" to "an" in "If a APS is the target of a link...". Editorial, 3.2.1.1The last word of item #7 should be "navigate", not "negotiate". Editorial, 3.2.1.1At the end of the second bulleted item, add the sentence: "The resulting view is a full-picture view, not a zoomed view". Editorial, 3.2.1.1After the bulleted list, add the following paragraph: "The case of default object behavior and no 'viewcontext' APS attribute requires a full-picture view, not a zoomed view. Some legacy intelligent graphics content, as well as some closely related IG profile, have specified that this case requires a zoomed view. The next functional edition of WebCGM will have explicit controls for this viewer behavior". Editorial, 3.2.1.32nd pgph, change "identifiing" to "identifying". Clarifications, 3.2.2.xSome of the sections 3.2.2.1 through 3.2.2.8 are unclear about attribute multiplicity. 3.2.2.1, add to the end of the first paragraph: "At most one 'region' attribute may be present within a single APS." 3.2.2.2, add to the end of the first paragraph: "At most one 'viewcontext' attribute may be present within a single APS." 3.2.2.4, add to the end of the first paragraph: "At most one 'LayerName' attribute may be present within a single 'layer' APS." 3.2.2.5, add to the end of the first paragraph: "At most one 'LayerDescription' attribute may be present within a single 'layer' APS." (This actually is stated in 3.2.1.2). 3.2.2.7, add to the end of the first paragraph: "Multiple 'name' attributes may be contained within a single APS." Editorial, 3.2.2.32nd paragraph: "the third string is (possibly null) is the a Behavior parameter" -- delete the first "is" and the "a". Editorial, 3.2.2.3Replace the last 4 paragraphs as follows: The destination of a link is specified by a Uniform Resource Identifier, or URI. Any valid URL under the specifications of RFC 2396 is a valid value of this parameter. This specification does not constrain the syntax or semantics of a URI 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 3rd 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 URI points to CGM media type, the picture behavior may be encoded within the optional fragment identifier in conjunction with the URI structure, per section 3.1.1, "Addressing Pictures and Objects". This form is deprecated, 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, but not both. Editorial, 3.2.2.6The content model in 3.3 shows that ScreenTip is not allowed within APS of type 'layer'. However, 3.2.2.6 states "This APS Attribute may occur within any valid APS of WebCGM". The latter is incorrect. Change "any valid APS of WebCGM" to "any graphical object of WebCGM, specifically, within any APS of type 'grobject', 'para', and 'subpara'." Editorial, 3.2.2.73rd pgph: insert a space in "withobjects". Clarification, 3.3Attribute Multiplicity & XML Content Model. The use of XML to express the content model in section 3.3 creates some unintended side effects. Specifically, an XML element can contain at most one instance of a particular XML attribute. On the other hand, WebCGM specifically allows multiple occurrences of some APS attributes types within some APS types, specifically 'linkURI' and 'name'. The best solution would be to switch over to BNF, but this should be deferred to the next functional Edition. For this maintenance release, add a caveat to the end of section 3.3: "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.8." Editorial, 3.3In the 9th line of the comments at the beginning of the content model, change "gprim" to "cgmprim", to match the last line of the content model. Editing Directives - CGM ProfileCorrection, 4.1Change three occurrences of 1992 to 1999. Correction, All of PPF, 4.1Align references to CGM:1999. Correction, 4.2 T13.1Remove reference to character encoding. Correction, 4.3 T.14.5Change 1992 to 1999. Correction, non-graphical characters, 4.3There are several mistakes, where the WebCGM rules conflict with the rules in XML, with which they are supposed to align. (These corrections are all forward compatible, in that no existing valid WebCGM content will be invalidated.) Correction, 4.3, T.14.5Change "ISO Latin 1, LHS" to "ISO Latin 1 (LHS & RHS)". (Not an XML-alignment issue, just a mistake). Correction, 4.3, T.14.5Delete the last sentence, after "Other:" Correction, 4.3, T.14.5Add to "Other:" the new sentence: "See 3.1.1 for additional restrictions to the character repertoire for those WebCGM non-graphical strings which may be part of the WebCGM URI fragment. Editorial, 4.4, T.15.9Correct the spelling of "APPLICACION". Correction, 4.5 T.16.1Change to "Same as Model Profile" Correction, 4.5 T.16.2Under 'other' clause, "Parameter strings are considered case insensitive." Correction, 4.5 T.16.13Add to 'other' clause, "Font names are considered case insensitive." Editorial, 4.5, T.16.14For "Maximum limit for the number of character sets in the character set list", change "5" to "6" (this change was overlooked when UTF-16 was added to the permissible sets during WebCGM development). Correction, 4.5 T.16.21Add to 'other' clause, "Parameter values are considered to be case insensitive." Correction, 4.6 T.16.4, T.16.5, T.16.6, T.16.7, T.16.8, T.16.12, 4.7 T.18.1, T.18.2Remove reference to character encoding. Correction, 4.6 T.16.23Replace references to 1738 and 1808 to 2396. Correction, 4.7 T.18.7, T18.8, and T18.9Change 1992 to 1999. Editorial, 4.9 T.20.2Change Object to Objects. Correction, 4.14 T.25.4Change reference to 8632:1999. Editorial, 4.14, T.25.4Replace "Record 7 of the graphics declaration file" (which is from the ATA profile) with "Specified in ISO/IEC 1999 Annex I for the core 13 fonts". Correction, 4.15 T.26.6Change reference to 8632:1999. Correction, 4.15 T.26.7Replace "defect correction" statement with "In CGM:1999, the following information was added to the MP." Editorial, 4.15, T.26.7In the section about CLIPPING MODEs, "EDGE" should be added to the list "LINE/MARKER/TEXT". A nicer way to write the latter might be something like "<LINE | MARKER | TEXT | EDGE>". Editorial, 4.16.2, T.13.6T.16.16 indicates that NAME PRECISION is 'prohibited'. T.13.6, the binary encoding specification for NAME PRECISION, incorrectly indicates 'permitted'. T.13.6 is wrong, and T.16.16 is correct. Change the first line - the permissibility of the element - in T.13.6 so that it matches T.16.16. Correction, 4.17Change 1992 to 1999. | ||||||||||||||||||||||||
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC