- From: Brian McBride <bwm@hplb.hpl.hp.com>
- Date: Thu, 02 Oct 2003 20:11:47 +0100
- To: Francois Yergeau <FYergeau@alis.com>
- Cc: Jeremy Carroll <jjc@hplb.hpl.hp.com>, w3c-i18n-ig@w3.org, w3c-rdfcore-wg@w3.org
Francois Yergeau wrote: > Brian McBride wrote: > >>[[ >>The string in both plain and typed literals SHOULD be in >>Unicode Normal >>Form C [NFC]. This is motivated by anticipation that [Charmod], >>particularly section 4 Early Uniform Normalization will become >>standardized practice. Implementations SHOULD accept strings >>which are >>not in Normal Form C and MAY issue a warning in such circumstances. >>]] > > > My personal opinion only: the first part would be consistent with the > current state of Charmod, in which most of the normalization-related > requirements have been softened to SHOULDs. > > The last part, however, is not consistent with the first. If data SHOULD be > normalized, then implementations SHOULD NOT accept it when not normalized > (but may, if "the full implications must be understood and carefully weighed > before choosing a different course" [RFC2119] is fulfilled) and SHOULD issue > a warning in such circumstances. I wonder if we might look at it this way. Lets be careful who we are talking to with these two statements. I suggest they are targetted at different audiences, and are compatible. When we say literal strings SHOULD be in NFC we are speaking to creators of RDF data saying you SHOULD create RDF literal strings that are in NFC (but MAY NOT, if "the full implications must be understood and carefully weighed). When we say that implementations SHOULD accept literal strings that are not in NFC we are talking to implementors who can rely on the creators of the RDF that is not in NFC to have made a sensible choice, but who MAY refuse to process it if they think they know better. Does that fly? Brian
Received on Thursday, 2 October 2003 15:13:59 UTC