RE: Weekly call for agenda items - I18N

   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:

http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Mar/0027.html

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
case.

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.


Jeremy

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