RE: Any update on TAG request?

Hi Larry,

> Sorry for being so grumpy about this... now I see the minutes of a June 29
> meeting (of? The minutes are unclear as to what / who met with what scope). 

As noted previously, the scope of this was unblocking CSS-Namespaces and discussing the future problem of CSS-Selectors. 

> I did also see on www-tag that Paul Cotton asked you to raise this as a HTML WG
> issue to meet one of their deadlines...Did that happen?

Yes.

> 
> After a little digging, I found
>   http://www.w3.org/wiki/I18N/CanonicalNormalization

> which seemed like a summary of the issues and some of the alternatives. Is that
> document still a valid summary?

That document was created by some of the CSS folks. I think it is overly complex in its choices, but represents a good summary.

> 
> it listed 7 choices, not 2.  You said you had two choices, so presumably some of
> the seven have been eliminated?

See previous email.

> 
> http://www.w3.org/International/wiki/CharmodNormSummary

> lists one draft recommendation, and asks for " Internationalization WG
> members are invited to insert comments during the review period" but doesn't
> identify what "the review period" is. What is the status of that document?

Its purpose is to provide a scratch space when building out a new Charmod-Norm. The "DRAFT Recommendations" section embodies our current WG thinking on normalization. We are still working on this document, although currently distracted by HTML5.

> 
> In addition, I've been struggling with IRI
> comparison/equivalence/canonicalization/normalization in the IETF IRI working
> group, and very recently split out
>   http://tools.ietf.org/html/draft-ietf-iri-comparison-00

> as a separate document with the hope of getting explicit focus on the issues. I
> would like to ask that document be added to the mix of background documents
> to review.

IRI is a very useful case. 

> 
> I think the other input needed is a clear summary of what existing widely
> deployed implementations currently DO. I haven't found that, especially around
> normalization of input methods.
> 
Currently, few implementations perform normalization. Much of the Web is normalized, but only by the happy coincidence that most legacy character encodings, keyboards, etc. happen to use a precomposed form.

Input methods/keyboards generally produce normalized input, although they do not *perform* or check for normalization. Some keyboards specifically produce non-normalized input. In particular, it is commonly noted that Microsoft's Vietnamese keyboard produces non-normalized input. Other languages have non-normalized keyboards or input methods and it has been reported that some of the tools for creating minority language keyboards, such as Microsoft's KLC, are difficult to make produce normalized input sequences.

Addison

Received on Friday, 19 August 2011 16:43:40 UTC