- From: Phillips, Addison <addison@amazon.com>
- Date: Fri, 30 Jan 2009 14:43:35 -0800
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Hello Lachlan and Webapps-WG, In our most recent teleconference [1], the Internationalization Core WG discussed the issue with normalization in Selectors-API. I'm sure you're already aware of the rapidly growing thread about normalization in CSS3 that resulted from our comments. Obviously this hasn't been resolved yet. In our call, I was delegated to write to your WG officially endorsing my previous comments (below), as well as to propose to our WG a "health warning" such as I suggested. Obviously, if CSS-WG addresses normalization this may affect the outcome of our discussion with webapps. However, I18N feels that our two WGs can construct a useful, informative, small, and relatively-painless bit of text to allow you to proceed. Please let us know if you think this an appropriate way to address this issue or if we can assist in any way to help you guys out. Kind Regards, Addison [1] http://www.w3.org/2009/01/28-core-minutes.html#action06 Addison Phillips Globalization Architect -- Lab126 Chair -- W3C Internationalization WG Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: public-i18n-core-request@w3.org [mailto:public-i18n-core- > request@w3.org] On Behalf Of Phillips, Addison > Sent: Tuesday, January 27, 2009 10:40 AM > To: Lachlan Hunt > Cc: public-webapps@w3.org; public-i18n-core@w3.org > Subject: RE: [selectors-api] Selectors API I18N Review... > > (This is a personal response) > > Hi Lachlan, > > I didn't expect any other response from you, really. > > At a minimum, I think we would expect a health warning or warnings > in the API spec, since Selectors themselves don't address the issue. > Our WG could recommend some appropriate text that is not too dire- > looking. > > > > While I understand that the > > CSSWG have not yet adequately addressed the i18n issues in their > > spec, there's nothing I can do to resolve that. > > I recognize that. For reasons I won't go into here, I note that > lack of maturity in CSS3 doesn't block your advancement. But > advancing your document without the issue being resolved might lead > to a "de facto" standard that is hard to overturn/undo. > > > I could not define any normalisation in this spec without > > indirectly > > affecting how selectors work in other specs that use them, like > CSS. > > I agree. But my concern looks something like: > > - You publish; various interoperable implementations are created > which do not address Unicode normalization. Normalization is not > addressed, since CSS3 hasn't dealt with it yet. > > - CSS3 later decides to address normalization. One of two outcomes > is possible: > > a. Defining normalization breaks the extant implementations; > tough luck for the implementers. > b. Everyone pretends that normalization isn't somehow important; > tough luck for users. > > We've been living in "world (b)" for some time now. The situation > is becoming less pretty as more languages that use combining marks > and compatibility forms come into common usage on the Web. So, as I > said, I think it likely that our WG will want to help you advance > in some useful (non-blocking) way. Our next meeting is tomorrow, so > look for a formal response from us shortly. > > Kind Regards, > > Addison > > Addison Phillips > Globalization Architect -- Lab126 > Chair -- W3C Internationalization WG > > Internationalization is not a feature. > It is an architecture. > > > > -----Original Message----- > > From: Lachlan Hunt [mailto:lachlan.hunt@lachy.id.au] > > Sent: Tuesday, January 27, 2009 9:39 AM > > To: Phillips, Addison > > Cc: public-webapps@w3.org; public-i18n-core@w3.org > > Subject: Re: [selectors-api] Selectors API I18N Review... > > > > Phillips, Addison wrote: > > > I am writing on behalf of the I18N Core WG who discussed the > > > Selectors API WD in our call of 3 December [1]. > > > > > > We reviewed the Selectors API working draft. In reviewing this > > draft, > > > we did not find any internationalization issues in the text of > > the > > > document. However, we would like to point out that the CSS3 > > Selectors > > > themselves have outstanding internationalization comments not > > > addressed in the current version of that document [4] and which > > would > > > (we think) impact anyone who were to implement the Selectors > API. > > Our > > > comments on CSS3 Selectors are located at [2]. We also note > that > > > Unicode Normalization is not treated anywhere in this draft or > in > > > CSS3 Selectors. > > > > I'm not sure how I can address this issue. While I understand > that > > the > > CSSWG have not yet adequately addressed the i18n issues in their > > spec, > > there's nothing I can do to resolve that. > > > > Since this API defers all processing requirements for selectors > to > > the > > selectors spec (with the exception of trimming whitespace), it is > > the > > responsibility of selectors to deal with Unicode normalisation > > issues. > > I could not define any normalisation in this spec without > > indirectly > > affecting how selectors work in other specs that use them, like > CSS. > > > > > We are concerned that changes in CSS3 might impact > implementation > > of > > > Selectors API and/or the text thereof and think our concerns > > probably > > > should be addressed before Selectors API advances to the next > > level > > > of maturity. > > > > I do not believe the limitations of Selectors can have a direct > > impact > > implementation of this API. > > > > This is the last issue I need to address before asking to have > this > > spec > > proceed to CR, so I would like to be able to resolve it as > quickly > > and > > as easily as possible. If you have any proposals as to how > exactly > > I > > can address it, I will certainly try and do so. > > > > -- > > Lachlan Hunt - Opera Software > > http://lachy.id.au/ > > http://www.opera.com/
Received on Friday, 30 January 2009 22:44:13 UTC