| Group Home
Page | Member-Confidential!
This is the public part of the Disposition of Comments received during the Last Call for comments on the Character Model for the World Wide Web 1.0, W3C Working Draft 26 January 2001. Each Last Call Comment (LCC) is associated with a Last Call Issue (LCI). Related LCCs may be grouped together into a single LCI. To find the disposition of an LCC, click on the link to the corresponding LCI, then check the status columns. For various reasons, several of the links in this document are Member-only.
Other versions of the Character Model: Latest public version | Latest internal version (Members only)
Related documents: Requirements for String Identity Matching and String Indexing | Minutes of I18N WG meetings (Members only)
Related mail archives: www-i18n-comments
The original comment is linked from the originator's name. Where a single mail contained multiple comments, these have been chopped up into separate mails linked from the Description. Where this is not the case, the links from the originator's name and from the Description are identical. The value of Visibility is either Public (indicating that the comment was sent to the www-i18n-comments list) or Member (indicating the comment was sent to the w3c-i18n-ig list).
Comments: 1 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 210 220 last
The three Status columns are:
The possible values of Accepted in principle are:
The possible values of Type are:
Issues: 1 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 last
| LCI | Status | T | Ref | Description | LCC | Comment | ||
|---|---|---|---|---|---|---|---|---|
| A | M | C | ||||||
| LCI-197 | N | - | Y | S | 4.3 | Should search engines
normalize? -- Responsibility for Normalization: "[S] [I] A text-processing component that receives suspect text MUST NOT perform any normalization-sensitive operations unless it has first successfully validated the text for normalization, and MUST NOT normalize the suspect text." I understand that some application such as XML processor MUST NOT normalize the suspect text because the normalization can turn a well-formed document to ill-formed. On the other hand, some application such as search engine SHOULD normalize text so that it can find canonically equivalent text. |
LCC-221 | comment-221 |
| LCI-196 | P | Y | Y | E | 3.7 | Delimiters for character
escaping -- Character Escaping: "[S] Explicit end delimiters MUST be provided. Escapes such as \uABCD where the end delimiter is a space or any character other than [01-9A-F] SHOULD be avoided." MUST and SHOULD are mixed here. If the first requirement is MUST, the second must be also MUST. |
LCC-220 | comment-220 |
| LCI-195 | Y | Y | Y | E | 3.7 | "character data" vs. "text
data" -- Character Encoding Identification: "[S] Specifications MUST NOT use heuristics to determine the encoding of data." In what situation, would specifications "determine" the encoding of data? |
LCC-218 | comment-218 |
| LCI-194 | Y | Y | Y | E | 3.6.2 | Would specifications "determine" the encoding of
data?-- Character Encoding Identification: "[S] Specifications MUST NOT use heuristics to determine the encoding of data." In what situation, would specifications "determine" the encoding of data? |
LCC-218 | comment-218 |
| LCI-193 | Y | Y | Y | E | 3.6.1 | "There is also no ambiguity if
data is transferred non-electronically ..." -- Mandating a unique character encoding: "There is also no ambiguity if data is transferred non-electronically and later has to be converted back to a digital representation." If "transferred non-electronically" means that characters are written on paper, there are a lot of ambiguity to determine characters from glyph, like if this space is SPACE U+0020 or NO-BREAK SPACE U+00A0. |
LCC-217 | comment-217 |
| LCI-192 | Y | Y | Y | E | 3.5 | XML doesn't allow use of full
range of Unicode code points and doesn't justify exceptions -- Reference Processing Model: In the first Note in this section, it says "All specifications that derive from the XML 1.0 specification [XML 1.0] automatically inherit this Reference Processing Model." But XML 1.0 is not very good example because it doesn't allow the use of the full range of Unicode code points and it doesn't justify the exceptions. |
LCC-216 | comment-216 |
| LCI-190 | y | Y | Y | E | 7 | String Indexing needs more examples | LCC-29 | comment-29 |
| LCI-188 | Y | Y | Y | S | 4.3 | Issue 5: Responsibilities "Proxy" versus "Recipient" | LCC-214 | comment-214 |
| LCI-187 | Y | Y | Y | S | 4.2.2 | Issue 3: Full Normalization as document syntax dependent | LCC-212 | comment-212 |
| LCI-186 | Y | Y | Y | S | 4.3 | Issue 2: XPath string-value | LCC-211 | comment-211 |
| LCI-185 | Y | Y | Y | E | 3.3 3.5 |
Transcoding | LCC-209 | comment-209 |
| LCI-184 | Y | Y | Y | E | 3.5 | Characters above U+10FFFF | LCC-208 | comment-208 |
| LCI-183 | P | Y | Y | S | 8 | IURIs, URIs, CHARMOD -- See also subsequent mail | LCC-207 | comment-207 |
| LCI-181 | Y | Y | Y | S | 4.2 4.3 |
State that W3C N11N is required | LCC-204 LCC-213 |
comment-204 comment-213 |
| LCI-180 | N | - | Y | S | 4 | Normalization vs. encoding layers -- See also subsequent mail | LCC-202 | comment-202 |
| LCI-179 | - | - | Y | S | 8 | This issue has been merged with LCI-8 | - | - |
| LCI-121 | Y | Y | Y | E | 2 | "... all applicable requirements MUST be satisfied." | LCC-144 | comment-144 |
| LCI-104 | Y | Y | Y | S | 4.3 | Critique of reliance on early normalization | LCC-125 | comment-125 |
| LCI-102 | N | - | Y | S | 4.3 | Concerns about impact of early normalization | LCC-123 | comment-123 |
| LCI-101 | N | - | Y | S | 4.2 | Concerns about NFC | LCC-122 | comment-122 |
| LCI-100 | - | - | Y | N | 8 | (Character Encoding in URI References): Discussion of DSig approach | LCC-121 | comment-121 |
| LCI-99 | - | - | Y | N | 4.3 | (Responsibility for Normalization): Discussion of DSig approach | LCC-120 | comment-120 |
| LCI-98 | - | - | Y | O | 4.2 | U+0Fnn (Tibetan Block) characters | LCC-126 | comment-126 |
| LCI-97 | - | - | Y | N | 4.3 | (Early Uniform Normalization): Discussion of DSig approach | LCC-119 | comment-119 |
| LCI-96 | Y | Y | Y | S | 3.7 | (Character Escaping): "There SHOULD be only one way to escape a character." -- See miscellany 40 | LCC-118 | comment-118 |
| LCI-95 | N | - | Y | S | 3.6.2 | (Private Use Code Points): Disagreement with our approach | LCC-117 | comment-117 |
| LCI-94 | - | - | Y | N | 3.6.1 | (Character Encoding Identification): Discussion of DSig approach | LCC-116 | comment-116 |
| LCI-93 | Y | Y | Y | E | 3.6 | (Choice and Identification of Character Encodings): Why do we say "For APIs, UTF-16 is more appropriate"? | LCC-115 | comment-115 |
| LCI-92 | N | - | Y | E | 3.2 | (Digital Representation of Characters): "the distinction between CEF and CES is not very clear and might merit an example" | LCC-113 | comment-113 |
| LCI-91 | Y | Y | Y | E | 3.1.5 | (Units of Collation): "Software developers MUST NOT merely use a one-to-one mapping as their string-compare function ..." | LCC-112 | comment-112 |
| LCI-90 | Y | Y | Y | E | 3.1.3 | (Units of Visual Rendering): Define "logical order" | LCC-111 | comment-111 |
| LCI-89 | Y | Y | Y | E | 3.1.2 | (Units of a Writing System, and Units of Aural Rendering): Define phoneme and syllabaries -- See also mail from Richard Ishida | LCC-110 | |