Disposition of Last Call comments for WebCGM 2.1

WebCGM WG Response:
Resolution:
The WebCGM WG thanks submitter for the comments on WebCGM 2.1. The WebCGM WG has the following responses to the comments:

1. Modify T.14.4, T.14.5 with the specific changes as proposed by submitter to double the limits in question;
2. fix the table cells in T.14.5 per submitter's "note" about ISO/IEC 8632-1:1999/Cor.2:2007(E).

Resolution archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Nov/0060.html

Response sent to commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2008Dec/0001.html

Response from commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2008Dec/0008.html

WebCGM WG Response:
Resolution: Change the method name 'union()' to 'unionRect()', as proposed by commenter. Changes will be made in: 5.7.1.2, 5.7.5 (setView), and Ch.8 (ECMAScript).

Resolution archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Nov/0060.html

Response sent to commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2008Dec/0002.html

Response from commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2009Jan/0021.html

WebCGM WG Response:
Resolution:
Replace the subject text in 5.7.6 (getObjectExtent description) with the following: "Other than text attributes and text-related Style Properties, the calculation is not affected by CGM Primitive Attribute (such as line width) or Control elements, nor by APS Attributes or non-text Style Properties..." [Also fix the link fragments in that section of text, which are all missing (empty, "#").]

Resolution archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Nov/0060.html

Response sent to commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2008Dec/0003.html

Response from commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2009Jan/0021.html

WebCGM WG Response:
Resolution:

1. remove the gzip requirement from T.13.1 in Chapter 6, by changing "Other: the whole metafile may be GZIP compressed. WebCGM interpreters must support GZIP-compressed metafiles." to "Other: none".
2. Add to the end of Section 7.1: "WebCGM 2.1 viewers, both static and dynamic, shall correctly handle valid WebCGM 2.1 Binary-encoded metafiles that are gzip-compressed. WebCGM 2.1 viewers that claim to correctly handle valid WebCGM metafiles of an earlier WebCGM version (1.0 or 2.0) according to the conformance rules of that earlier version, shall correctly handle such metafiles when they are gzip compressed."
3. In section 2.4, change ""6.2 Metafile rules" to "7.1 Conformance definitions", and link the latter to "WebCGM21-Conf.html#webcgm_conformance_CoP"

Resolution archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Dec/0038.html

Response sent to commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2008Dec/0005.html

Response from commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2009Jan/0021.html

WebCGM WG Response:
Resolution:

Thank you for pointing that out. The formatting will be corrected.

Resolution archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Nov/0060.html

Response sent to commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2008Dec/0009.html

Response from commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2009Jan/0001.html

WebCGM WG Response:
Resolution:

Clarify text by changing:
"The list syntax and normalization are derived from the specifications of CSS 2.0 [@@CSS20@@]. In particular, the values and syntax of the substitutionList attribute are derived from CSS's definition of the @@font-family@@ property:"
to:
"The values and syntax of the substitutionList attribute, as well as the normalization of that attribute, are derived from the definition of the @@font-family@@ property in CSS2 2.0 [@@CSS20@@]:"

[Ed-note: @@font-family@@ denotes text "font-family" that links to:
http://www.w3.org/TR/CSS2/fonts.html#font-family-prop ;
@@CSS20@@ denotes text "CSS20" that links to the WebCGM 2.1 references list, which in this version is:
http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-Intro.html#CSS20 ]

Resolution archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Nov/0060.html

Response sent to commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2008Dec/0010.html

Response from commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2009Jan/0002.html

WebCGM WG Response:
Resolution:

This was a deliberate choice. The 'cgmFont' normalization defines, before the string-match comparison is performed, how to prepare both the font name extracted from WebCGM instance and the parameter value of the 'cgmFont' attribute. The rule is based on extensive real-world usage of CGM and WebCGM, both current usage and legacy usage. The WebCGM specification itself (T.16.13 of section 6.5 [1]) has since 1999 required a core set of fonts, or their metric equivalents, with names such as "Helvetica-BoldOblique". But the specifications allowed no trivial variations (e.g., blanks, underscore-for-hyphen, etc), other than "case insensitive". In reality, there is now a large legacy of files that conform to profiles closely related to WebCGM (e.g., ATA) but that have trivial difference in these names, or that are WebCGM instances with trivially erroneous variations on the names. The purpose of the 'cgmFont' normalization is to enable the application of the font substitution mechanism to this substantial legacy of CGM instances.

On the other hand, the 'substitutionList' attribute of the WebCGM specification defines the set of fonts from which a substitute is to be selected. This font substitution mechanism is a new feature of WebCGM, and so there is no legacy to consider for 'substitutionList'. The best design of syntax and mechanism, and one that is already used by some WebCGM constituents in other contexts, comes from the CSS 2.0 specification. This was therefore closely adapted to the needs of WebCGM 2.1's font substitution mechanism.

[1] http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-Profile.html#webcgm_4_5

Resolution archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Nov/0060.html

Response sent to commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2008Dec/0011.html

Response from commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2009Jan/0003.html

WebCGM WG Response:
Resolution:

The intent is indeed "stripping out all whitespace". This enables identical normalization results, for example, for a font name that used whitespace instead of camel case on the one hand, and on the other hand a font name that used only camel case (with no whitespace), or one that used hyphen or underscore in place of whitespace. These are legacy situations that arise in WebCGM practice. Please see the response to I18N WebCGM Comment #3 for more detail.

Resolution archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Nov/0060.html

Response sent to commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2008Dec/0012.html

Response from commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2009Jan/0004.html

WebCGM WG Response:
Proposed resolution:

The apparent restriction to Latin 1 was unintended. As you point out, the normalization would work the same if the same names were expressed in Latin 2. Latin 1 got the special mention because: 1.) the default character encoding of WebCGM is ISO 8859-1; and, 2.) the vast majority of current and legacy WebCGM instances use this character encoding and a restricted core set of thirteen specific font names. As pointed out in WebCGM's reply to I18N's issue #3, these WebCGM-specific normalization rules were targeted at the substantial volume of legacy and current metafiles that intend to invoke this restricted core set of fonts, but that contain well-known, trivial deviations in the construction of the names. In other words, the real target is trivially deviant usage of the 13 specific core-font names, regardless of the character encoding. (More background: the valid character encoding for any particular WebCGM instance is one of the three ISO 8859-1, unicode UTF-8, or unicode UTF-16.)

WebCGM will reword to clarify the useful scope of these normalization rules, to remove the implication of a normative restriction of applicability, and instead to be advisory about the usefulness of that normalization outside of its primary intended scope. Replace the two quoted sentences in question (in the 9.3.2.2 description of 'cgmFont') with:

"Note: These normalization rules are derived from and intended for the substantial volume of existing metafiles that aim to invoke fonts from WebCGM's restricted core set of thirteen specific fonts (see T.16.13 of @@section 6.5@@) and that contain well-known and trivial deviations in the construction of those font names. The rules may be less useful outside of that intended scope. The target metafiles of these normalizations are most often, but not always, encoded in WebCGM's default character encoding of ISO 8859-1."

[Ed-note: @@section 6.5@@ denotes text "section 6.5" that links to "WebCGM21-Profile.html#webcgm_4_5", which in the LCWD version is:
http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-Profile.html#webcgm_4_5 ]

Resolution archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Dec/0064.html

Response sent to commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2008Dec/0013.html

Response from commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2009Jan/0005.html

WebCGM WG Response:
Proposed resolution:

WebCGM agrees that this is the consistent and reliable way to perform such comparisons. Text to this effect will be added to the description of the 'cgmFont' value -- conversion to unicode normalization form should precede the comparison and follow the other WebCGM-specific normalization.

In 9.3.2, add a new sentence to the end of the description of 'cgmFont': "After this WebCGM-specific normalization, correct and consistent results when comparing metafile font names with the 'cgmFont' value — for font names outside of WebCGM's restricted core set of thirteen specific fonts (see T.16.13 of @@section 6.5@@) — may require that WebCGM processors convert to a @@unicode normalization form@@ before performing the string comparison." Also add to WebCGM Chapter 1 the references for both the Unicode Standard Annex #15 [1] and the W3C Character Model, Part 2 (Normalization) [2].

[1] http://www.unicode.org/reports/tr15/
[2] http://www.w3.org/TR/charmod-norm/

Incorporating all proposed changes, the paragraph of 'cgmFont' description becomes:

"The name of the font in the metafile for which font substitution is requested. Before attempting to match a font used in the metafile to the value (string) of cgmFont, both font names are normalized by a WebCGM-specific normalization: convert to lower-case; and strip out all whitespace, UNDERSCORE, and HYPHEN characters. Note: These normalization rules are derived from and intended for the substantial volume of existing metafiles that aim to invoke fonts from WebCGM's restricted core set of thirteen specific fonts (see T.16.13 of @@section 6.5@@) and that contain well-known and trivial deviations in the construction of those font names. The rules may be less useful outside of that intended scope. The target metafiles of these normalizations are most often, but not always, encoded in WebCGM's default character encoding of ISO 8859-1. After this WebCGM-specific normalization, correct and consistent results when comparing metafile font names to the 'cgmFont' value — for font names outside of WebCGM's restricted core set of thirteen specific fonts — may require that WebCGM processors convert to a @@unicode normalization form@@ before performing the comparison."

[Ed note: @@section 6.5@@ denotes text "section 6.5" that links to "WebCGM21-Profile.html#webcgm_4_5", which in the LCWD version is:
http://www.w3.org/TR/2008/WD-webcgm21-20080917/WebCGM21-Profile.html#webcgm_4_5;
@@unicode normalization form@@ denotes text "unicode normalization form" that links to:
http://www.w3.org/TR/charmod-norm/#sec-ChoiceNFC ]

Resolution:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Dec/0064.html

Response sent to commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2008Dec/0015.html

Response from commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2009Jan/0006.html

WebCGM WG Response:
Proposed Resolution:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Nov/0062.html

1. In the text description of getObjectExtent (section 5.7.6), change "abstract locus" to "locus", and link "locus" to a new Glossary definition in Appendix C.
2. Add this definition to the Glossary (Appendix C):
   locus --
   

   A general definition from the Oxford dictionary defines 'locus' as: "Curve formed by all points satisfying particular equation of relation between coordinates, or by point, line, or surface, moving according to mathematically defined conditions." In the WebCGM specification, locus refers to the set of points that comprise the path or shape of a Graphical Primitive element, or in the appropriate context, the combined shapes or paths collectively of all of the Graphical Primitive elements in an Application Structure (APS). I.e., the locus of an APS comprises the combined loci of all of the graphical primitives in the APS. Locus does not include defining data that are not part of the shape or path of the graphical primitive, such as control points of Bezier primitives, or the center point of a Circular Arc Center primitive.

(Ed note. The WG closes the present issue with this resolution, anticipating that further detailed questions of clarification will arise as implementations progress.)

Resolution archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Dec/0038.html

Response sent to commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2008Dec/0004.html

Response from commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2009Jan/0021.html

WebCGM WG Response:Resolution:

Add wording to setView() description: "The viewer shall fit the NVDC rectangle specified by the 'viewRect' parameter into the viewer’s display rectangle and center it, while maintaining the aspect ratio of the 'viewRect' rectangle."

Resolution archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Dec/0038.html

Response sent to commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2008Dec/0006.html

Response from commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2009Jan/0021.html

WebCGM WG Response:
Resolution:

In the IDL, change the setView return type from 'void' to 'boolean'; in the setView() description, change the return value from "No return value." to " boolean: TRUE if new view was set; FALSE if rectangle was invalid and the view could not be set." In the ECMAScript in Chapter 8: change "setView(view)" to "setView(viewRect); change the associated "This method has no return value" to "This method returns a Boolean".

Resolution archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2008Dec/0038.html

Response sent to commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm/2008Dec/0007.html

Response from commenter is archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2009Jan/0021.html

WebCGM WG Response:
Resolution:

Thank you for your comments during the WebCGM 2nd Last Call Working Draft (LCWD) review.

1- First comment : == moving forward with XML Schema or Relax NG ==

The WebCGM Working Group (WG) agrees that WebCGM could potentially benefit by addition of a normative schema -- XML Schema or Relax NG. Unfortunately, this proposal is beyond the scope of this 2nd LCWD review, and it is deemed to be too late in the WebCGM 2.1 development cycle. Ideally, such a proposal would have been included in the WebCGM 2.1 Requirements, or before 1st LCWD review at latest. The implementation of such a proposal would involve major disruption of the WebCGM 2.1 text -- removal of the DTD and complete rewriting of Chapter 4 (at least). Since it does not address an error in the specification, or a serious defect, or violation of any W3C requirement, the WG believes that the proposal should be postponed until a future WebCGM development cycle.

As an interim step, the WG thinks that a non-normative Technical Note, separate from the progression of 2.1 WebCGM, might be an interesting approach. The WG would also welcome an initial contribution, if you have interest in making such.

2- Second comment : == interaction between WebCGM and CSS ==

Potential relationships between WebCGM and CSS were studied in some detail [1] prior to the WebCGM 2.0 standardization. This study [1] developed a detailed model and showed the technical feasibility for a rich application of CSS-like styling to WebCGM.
[1] http://www.cgmopen.org/technical/stylable_cgm_submitted_0324.pdf

Despite the technical feasibility, the WebCGM 2.0 authors and constituents agreed that the the principal WebCGM use cases did not justify the cost and implementation effort of such a full-featured normative CSS capability in WebCGM. Therefore normative CSS-like style sheets were not further pursued.

Nevertheless, whenever possible, applicable features and characteristics of CSS were followed in the design of WebCGM 2.0, especially the new DOM-based Style Properties feature. For example the inheritance model of CSS was adapted directly into the Style Properties inheritance model (section 5.4), and there are a number of other examples of functionality borrowed more-or-less directly from CSS.

Resolutions archived at:
http://lists.w3.org/Archives/Public/public-webcgm-wg/2009Jul/0019.html
and
http://lists.w3.org/Archives/Public/public-webcgm-wg/2009Jul/0005.html

Response sent to commenter is archived at:

http://lists.w3.org/Archives/Public/public-webcgm/2009Jul/0000.html

Response from commenter is archived at:

1- First comment about Schema is agreed by commenter

http://lists.w3.org/Archives/Public/public-webcgm/2009Aug/0001.html

2- Second comment about interaction between WebCGM and CSS. The WG agrees to add an informative note it in the spec. Agreed by commenter

http://lists.w3.org/Archives/Public/public-webcgm/2009Aug/0001.html

http://lists.w3.org/Archives/Public/public-webcgm/2009Aug/0003.html