Last modified: $Date: 2007/10/15 13:59:11 $
Copyright © 2007 W3C® (MIT, ERCIM, Keio). All Rights Reserved. W3C liability, trademark and document use rules apply.
The WebCGM 1.0 Recommendation was produced by collaboration of the W3C and the CGM Open Consortium.
This document lists the known errata to the WebCGM 1.0
Recommendation.
Each entry has the following information:
Please send general comments about this document to the public mailing list [email protected]. An archive is available at http://lists.w3.org/Archives/Public/public-webcgm/.
Added text marked thus. Removed text marked thus. Changed text marked thus.
The processing of errata is governed by the errata process defined in the W3C Process document.
For all errata listed on this page, it is the consensus of the WebCGM Working Group that they are correct and appropriate. They are not to be considered normative until approved by a Call for Review of Proposed Corrections or a Call for Review of an Edited Recommendation.
- E01: clarification of non-URI characters, IRIs, RFCs 2396/3986/3987.
Description:
Date of this entry: 18 June 2007
(Most recent update: 30 August 2007)
Class: Class 2.
Overview: During the generation of the text of WebCGM 2.0, it became clear that the text of WebCGM 1.0 section 3.1.1.4, "Non-ASCII Characters in URIs", was interpreted in two different ways by implementations. In fact, both interpretations are valid cases of the correct specification, and this was clarified in WebCGM 2.0 section 3.1.1.4, "Non-URI characters in IRIs".
This erratum applies the same clarification to WebCGM 1.0, updates the usage of "URI" to "IRI" throughout (where appropriate), and updates the RFC2396 reference(s) with RFC3986 and RFC3987.
Proposed fix:
The proposed fix has the following several parts:
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.cgmApplication 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#wheelAssemblyThe 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.
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.
WG-approved Resolution:
At its 20070830 teleconference, the WebCGM WG approved and endorsed the Proposed fix as described.
- E02: editorial errors in 3.4 <OBJECT> specification.
Date of this entry: 18 June 2007
(Most recent update: 30 August 2007)
Class: Class 2.
Overview: There are errors in the <OBJECT...> element illustration following the first paragraph of section 3.4. The ";" that occurs after "WebCGM" should not be there. The WIDTH and HEIGHT attributes should be quoted.
The terminology "OBJECT tag" is incorrect. It should be "OBJECT element".
It is also implicit in section 3.4, but never stated explicitly, that the values of the attributes of the <PARAM> element are to be treated as case insensitive by WebCGM viewers. See for example the various treatments of 'middle' in the text and examples. This is also consistent with the Ch.4 PPF convention of case insensitivity wherever possible in non-graphical text. See, for example, the sub-strings of the METAFILE DESCRIPTION element (T.16.2 of section 4.5) and the font names in the FONT LIST element (T.16.13 of section 4.5).
Proposed fix: The proposed fix has three parts:
E02.1: In section 3.4, change
<OBJECT DATA="xxx.cgm" TYPE="image/cgm;Version=4;ProfileId=WebCGM"; WIDTH=200; HEIGHT=100>
to
<OBJECT DATA="xxx.cgm" TYPE="image/cgm;Version=4;ProfileId=WebCGM" WIDTH="200" HEIGHT="100" >
E02.2: In section 3.4, in the title (once), first paragraph (once), and second paragraph (once), change
OBJECT tag
to
OBJECT element
E02.3: In section
3.4, add this sentence to the end of the paragraph that immediately
precedes the definition list of <PARAM> definitions, i.e.,
immediately before the line "FIXED No|Yes": "The names
and the permissible values are case-insensitive."
WG-approved Resolution:
At its 20070830 teleconference, the WebCGM WG approved and endorsed the Proposed fix as described.
- E03: correction (->example) of text search matching in para (3.2.1.3)
Date of this entry: 18 June 2007
(Most recent update: 30 August 2007)
Class: Class 2.
Overview: Email reference: http://lists.w3.org/Archives/Public/public-webcgm-wg/2007Aug/0007.html
During the writing of 2.0, it was agreed that it was inappropriate that text in 1.0 presented potential search algorithms in such a way that they might be confused with with normative specifications. Therefore 2.0 removed these from the normative text paragraphs [3] and explicitly made them into EXAMPLES of how one might build application-dependent search protocols on the standardize APS and ApsAttr elements.
Proposed fix: In WebCGM 1.0 section 3.2.1.3 delete the two paragraphs that begin with "Viewer Behavior. The...", and replace them with the text of Webcgm 2.0 section 3.2.1.3 that begins with "Viewer Behavior. With..." and extends through the boxed example.
WG-approved Resolution:
At its 20070830 teleconference, the WebCGM WG approved and endorsed the Proposed fix as described.
- E04: alignment of 3.3 & 3.1.2.3 regarding 'name' occurrence in 'para' & 'subpara'
Date of this entry: 11 July 2007
(Most recent update: 30 August 2007)
Class: Class 2.
Overview: In WebCGM 1.0 section 3.1.2.3, it is clear that the 'name' APS Attribute is allowed within APS of type 'para' and 'subpara'. In the content models of section 3.3, it has been omitted from 'para' and 'subpara'.
Proposed fix: Add 'name' to the content models of 'para' and
'subpara' in 3.3 as follows. In each of the attribute-declaration productions
"<!ATTLIST para ..." and "<!ATTLIST subpara
...", after the line "screentip CDATA #IMPLIED", add the
line "name CDATA #IMPLIED" .
WG-approved Resolution:
At its 20070830 teleconference, the WebCGM WG approved and endorsed the Proposed fix as described.
- E05: clarification of viewer handling of MITRE LIMIT
Date of this entry: 11 July 2007
(Most recent update: 30 August 2007)
Class: Class 3.
Overview: There is ambiguity in the WebCGM definition of MITRE LIMIT. The problem actually resides in the MITRE LIMIT definitions of CGM:1999 itself, and ultimately there should be a defect correction there. The definition in CGM:1999 and WebCGM does not match the commonly used definitions that are embedded in the Microsoft Windows operating system and in printers that run Adobe software. It was the intention of WebCGM that WebCGM implementations should be able to use commonly available hardware/firmware facilities to implement MITRE LIMIT.
This was fixed in WebCGM 2.0, by adding new interpreter implementation guidelines for MITRE LIMIT (section 4.15, entry T.26.7), and adding a reference to those guidelines from the MITRE LIMIT description (section 4.7, entry T.18.15). (Ultimately there should be an ISO 8632 defect correction.)
Proposed fix: Fix T.18.15 and T.26.7 in WebCGM 1.0 so that they match the same entries in 2.0 as follows:
Other: Mitre Limit handling: The handling of MITRE LIMIT in CGM:1999 6.5.6 is considered to contain errors, and an ISO erratum is being pursued. The following variation shall be considered conforming for the WebCGM profile, and is the preferred method when mitred line joins are rendered.
- When the projected join point would exceed the mitre length, measured from the intersection of the inside edges of the lines at the join, then the join is rendered as a bevel style. (CGM:1999 says that the projecting point is truncated at the mitre length).
- Any value of MITRE LIMIT that is less than 1.0 shall be mapped to 1.0.
WG-approved Resolution:
At its 20070830 teleconference, the WebCGM WG approved and endorsed the Proposed fix as described.
- E06: contradictory specifications of object behaviors in 3.1.2.4 & 3.2.1.1
Date of this entry: 20 August 2007
(Most recent update: 24 August 2007)
Class: Class 3.
Overview: See Item #1 in email reference: http://lists.w3.org/Archives/Public/public-webcgm-wg/2007Aug/0001.html
3.1.2.4 and the bullet list in 3.2.1.1 directly contradict each other now. After considerable discussion and a special teleconference, the WebCGM technical experts finally settled that what is described in 3.1.2.4 (for object behaviors other than view_context) is correct. The contradictory specifications (i.e., the bullet list) in 3.1.2.4 should have been deleted in the preparation of WebCGM 1.0 Second Release text, but were not.
Proposed fix: Delete the bullet list in section 3.2.1.1, and in its immediately preceding sentence change
the default behavior of the viewer shall be as follows:
to
the default behavior of the viewer shall be as described in "3.1.2.4 Object behaviors."
WG-approved Resolution:
At its 20070830 teleconference, the WebCGM WG approved and endorsed the Proposed fix as described.
- E07: ambiguous applicability of "128" limit in CLOSED FIGURE (PPF)
Date of this entry: 20 August 2007
(Most recent update: 30 August 2007)
Class: Class 2.
Overview: See Item #2 in email reference: http://lists.w3.org/Archives/Public/public-webcgm-wg/2007Aug/0001.html
It is asserted by the authors of the Model Profile and WebCGM profile that the limit of 128 elements within a CLOSED FIGURE is meant to apply to graphical primitive elements: "There is no logical reason to include attribute elements. The purpose of the limit is to make predictable the resource requirements of the viewer, and attribute elements have negligible bearing on that."
Because this is not explicitly stated, the PPF as written (T.15.4 in section 4.4) could be read as applying to all elements, as opposed to only graphical primitive elements. Whereas the ultimate solution would involve a CGM:1999 defect correction, the practical companion solution is for the working profiles (WebCGM, ATA, etc) to explicitly clarify what seems to have been almost universally assumed.
Proposed fix:
In the row that immediately follows T.15.4 of section 4.4, add to the WebCGM Profile column (the middle column) the following:
Note. The limit of 128 on "number of elements" refers specifically to graphical primitive elements. Other elements that might be included within the CLOSED FIGURE element, e.g., primitive attribute elements, do not count against the limit.
WG-approved Resolution:
At its 20070830 teleconference, the WebCGM WG approved and endorsed the Proposed fix as described.
- E08: confusion about multiple viewers, 'name' in <object> and <param>
Date of this entry: 20 August 2007
(Most recent update: 30 August 2007)
Class: Class 2.
Overview: See Item #3 in email reference: http://lists.w3.org/Archives/Public/public-webcgm-wg/2007Aug/0001.html
This sample of a larger discussion thread gives some flavor of this complicated issue:
The issue is NOT about the WebCGM 'name' APS attribute. It is about the
old text in WebCGM
1.0 section 3.1.4. The first paragraph, about addressing multiple
viewers, the <object> element, etc., was totally confused
and wrong.
The solution options are:
Proposed fix: Delete first paragraph of section 3.1.4. Replace the second paragraph with, "The Document Object Model (DOM) of WebCGM 2.0 provides a standard basis for addressing this problem."
WG-approved Resolution:
At its 20070830 teleconference, the WebCGM WG approved and endorsed the Proposed fix as described.
- E09: broken contact address for problem reports
Date of this entry: 24 August 2007
(Most recent update: 30 August 2007)
Class: Class 1.
Overview: Email reference: http://lists.w3.org/Archives/Public/public-webcgm-wg/2007Aug/0012.html
The contact point for reporting problems, "[email protected]", is broken.
Proposed fix:
On the cover page, change
"Please report errors in this specification to the WebCGM document editor.[[email protected]]"
to
"Please report errors in this document to the public mailing list <[email protected]>. An archive is available at http://lists.w3.org/Archives/Public/public-webcgm/."
WG-approved Resolution:
At its 20070830 teleconference, the WebCGM WG approved and endorsed the Proposed fix as described.
- E10: deviations of WebCGM 1.0 Model Profile from normative ISO CGM standard
Date of this entry: 21 August 2007
(Most recent update: 30 August 2007)
Class: Class 2.
Overview: Email reference: http://lists.w3.org/Archives/Public/public-webcgm-wg/2007Aug/0007.html
During the creation of the original WebCGM 1.0 in 1999, a version of the Model Profile PPF template with editorial deviations from the correct CGM:1992 Amd.2 PPF was mistakenly used. The deviations were discovered and fixed in 2.0, and some of them before that in 1.0 Second Release, but some of the deviations still exist in 1.0 Second Release. Most do not affect the WebCGM Profile specifications (the middle column of the PPF), either directly or indirectly.
Analysis of all of the deviations revealed four editorial bugs that affect the WebCGM Profile (middle column of the PPF).
Proposed fix:
WG-approved Resolution:
At its 20070830 teleconference, the WebCGM WG approved and endorsed the Proposed fix as described.
- E11: ambiguity on position of radius in degenerate elliptical arc close
Date of this entry: 21 August 2007
(Most recent update: 30 August 2007)
Class: Class 2.
Overview: See Item #5 in email reference: http://lists.w3.org/Archives/Public/public-webcgm-wg/2007Aug/0010.html
T.26.10 in WebCGM 1.0 section 4.15 adopts for WebCGM the treatments of degenerate graphical primitives that are recommended in annex D of CGM:1999. CGM:1999 D.4.5.12 specifies that coincident start ray and end ray in ELLIPTICAL ARC CLOSE should result (among other things) in drawing of a radius. It is implicit, but not explicitly stated, that the radius is drawn along the coincident start-end rays -- this is the only locations that fits the rationale behind the choice of fallbacks for such degeneracies. (Ultimately, there should be a CGM:1999 defect correction to put the explicit statement into D.4.5.12.)
Proposed fix:
Clarify in T.26.10 of WebCGM 1.0 section 4.15 that the drawn radius is along the start-end rays. In the row following the line containing "T.26.10", add to the WebCGM Profile column (the middle column) the following:
Note. For degenerate ELLIPTICAL ARC CLOSE, the radius specified in D.4.5.12 is drawn along the coincident start-end rays.
WG-approved Resolution:
At its 20070830 teleconference, the WebCGM WG approved and endorsed the Proposed fix as described.
- R01: TBD (revised @@ @@ 2007)
Description:
Tbd
Resolution:
Tbd