W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > March 2002

RE: Weekly call for agenda items - I18N

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Thu, 7 Mar 2002 11:43:17 -0000
To: "Brian McBride" <bwm@hplb.hpl.hp.com>, "RDF Core" <w3c-rdfcore-wg@w3.org>

   o charmod uri

I think we can make substantial progress on both I18N issues by agreeing a
response to the test case examples I posted in:


Do we think:

1: this is an RDF problem (i.e. present in the graph)
2: this is an XML problem (i.e. present in the XML serialization only)
3: this is not a problem (e.g. to be addressed, if at all, at the
application layer)

(More - rambling ...)

Given such a response I could go away and draft resolutions to both issues,
and justify them on that basis.

If 2 or 3 then we should document that and close the charmod-literal issue.
(If these examples are not compelling then I don't think that there will be
compelling examples). The charmod-uri issue is not impacted by this test

If 1 then a solution is:
- prohibit RDF string literals that are not in NFC.
- treat a URI before %-escaping and its %-escaped version as distinct in the
RDF graph
- explicitly allow the uriReference production to match original character
sequence (in UTF-8) URIs.
- prohibit the use of non NFC 'URIs' in RDF.

I note that the issue is exemplified by the archive web page, looking at the
in-line RDF example with Internet Explorer 5.5, and looking at the same
example with view source. Depending on what tools you have available you may
or may not get the same effect.

The view I have displays the two "#Andre" strings identically (which
conforms with unicode), whereas my view source mode does not.

Received on Thursday, 7 March 2002 06:49:33 UTC

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