- From: Martin Duerst <duerst@it.aoyama.ac.jp>
- Date: Mon, 02 Jul 2007 20:51:32 +0900
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: public-i18n-core@w3.org, public-iri@w3.org
Hello Bjoern, Many thanks for your quick feedback. I have submitted a first version of the draft with the wording below, but this is only a start. At 17:52 07/07/02, Bjoern Hoehrmann wrote: > >* Martin Duerst wrote: >>I have assigned this issue the following id: transcodeNFC-103 >>(http://www.w3.org/International/iri-edit/#transcodeNFC-103). >> >>I have changed the wording in step 1.b. of Section >>3.1. Mapping of IRIs to URIs from: >> >> b. If the IRI is in some digital representation (e.g., an >> octet stream) in some known non-Unicode character >> encoding, convert the IRI to a sequence of characters >> from the UCS normalized according to NFC. >> >>to: >> >> b. If the IRI is in some digital representation (e.g., an >> octet stream) in some known non-Unicode character >> encoding, convert the IRI to a sequence of characters >> from the UCS. The resulting sequence of characters >> SHOULD be normalized using NFC. >> >>Any comments welcome! > >There should be no SHOULD, it's critical that applications get this >right. What exactly do you mean by "applications get this right", and how would you put that in words? >Where normalization is necessary or beneficial, it should be >applied to the text content before any IRI processing takes place. That wouldn't be in conflict with the text above, or would it? >Besides, this does not resolve disputes as to when step b) would apply >at all. Do you mean that the phrase "non-Unicode character encoding" is not well defined? In my view, it's pretty obvious in practice. What would be the encodings where you don't know whether this applies or not? Do you have a better definition, or another proposal? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
Received on Monday, 2 July 2007 12:00:59 UTC