I18n WG comments on SVG Tiny 1.2

Version reviewed

http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/

Main reviewer

Felix Sasaki fsasaki@w3.org

Notes

These comments have been endorsed by the I18N Core WG.

Comments

ID	Location	Comment	Additional information	Accepted
1	Appendix G on i18n support	In your mail about i18n review of SVG Tiny 1.2 you mention that XML 1.1 is a normative reference of the specification. Nevertheless, in the section on Compatibility with Other Standards Efforts you only mention XML 1.0 We are wondering what the role of XML 1.1 in your specification is. Also related to this is the section on Conforming SVG Document Fragments. You mention XML 1.1. as the basis for well-formed SVG document fragments, but you use an RELAX NG　schema to describe SVG Tiny 1.2 validity. To our knowledge RELAX NG only supports XML 1.0, cf. the RELAX NG spec. So the question is how you want to support XML 1.1 during validation of SVG tiny documents.	For responses see here	-
2	Appendix G on i18n support	You mention several times the normalization part of the character model specification. The charmod-spec has been splitt into several parts. Please add a reference to the specification charmod-norm, You may wish to reference the matrial in CharMod Fundamentals in addition.	-	-
3	Sec. 10.2 on characters and glyphs, bullet point on composite characters	You write about Composite characters: "In this situation, a single Unicode character maps to multiple glyphs.". The example should be changed to explicitly reference the pre-composed character U+00E8, since Unicode also allows for the separate representation of base characters and combining marks.	-	-
4	Sec. 10.3 on Fonts, font tables and baselines	Comments on this section should be made by somebody who has detailed knowledge in this area. (Personal remark by Felix Sasaki)	-	-
5	Sec. 10.6.2	The reference to the Bidirectional Algorithm of Unicode is wrong. The proper reference to Unicode Bidi is the Unicode technical report for the BIDI Algorithm.	-	-
6	Generel (and e.g. comment 8)	It would be great to have somewhere in the spec an overview / a summary of the properties you are defining and their relation to CSS properties.	-	-
7	General	On readbility: The document contains parts of the RELAX NG schema, which are often referenced in the text. You might think about adding more links from that inner-textual references to the respective <div> sections with the schema definitions, to provide better readability.	-	-
8	Sec. 10.9	You describe the font selection properties in terms of CSS2-fonts. I would be great if you could clarify what related to CSS2-fonts and what is SVG-specifc. E.g. the value "Percentages" of the property font-size is not part of CSS2-fonts, but it is not marked as SVG-specific.	-	-
9	Sec. 10.10	The example doesn't use xml:space="preserve" and so you cannot see the example.
10	Sec. 10.10	You could adopt the whitespace handeling of CSS-2.1. If not, please tell us why.	-	-
11	Sec. 10.12	Vertical text functionality is not part of this SVG profile, e.g. you don't provide functionality for this. Do you plan to have such functionality in a later version of this spec? If not, please tell us why.	-	-
12	Genereal and e.g. in sec. 17.4 or sec. 5.8.5	You should use the standard terminology for dealing with RFCs: "RFC3066 or its successor". In this section, you say: "... Evaluates to "true" if one of the languages indicated by user preferences exactly equals one of the languages given in the value of this parameter, or if one of the languages indicated by user preferences exactly equals a prefix of one of the languages given in the value of this parameter such that the first tag character following the prefix is '-'. " This appears backwards to us. The "systemLanguage" parameter should represent a range, i.e. it should be the prefix. If I specify: <text systemLanguage="en">blah blah</text> And my system's actual language is "en-US", then the systemLanguage of "en" represents a prefix (language range is the correct term) that matches "en-US". The current formulation is exactly backwards. Also, the other RFC 3066 replacement, i.e. for matching might be of interest for you.	-	-
13	Sec. 5.8.5	You write about the systemLanguage attribute: "However, just because multiple languages are present within the object on which the systemLanguage test attribute is placed, this does not mean that it is intended for multiple linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly intended to be used by an English-literate audience. In this case, the systemLanguage test attribute should only include "en"." The note on Authoring Techniques for XHTML & HTML contains a defintion of primary and text processing language, which might be useful for you.	-	-