W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2003

Re: Fwd "a comment on NFC"

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Thu, 02 Oct 2003 20:11:47 +0100
Message-ID: <3F7C7873.6050107@hplb.hpl.hp.com>
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 

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?

Received on Thursday, 2 October 2003 15:13:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:26 UTC