RE: Outstanding Issues - rdf-charmod-literals

> rdf-charmod-literals: Does the treatment of literals conform to charmod ?

> We need an owner to check this.


While I would prefer not to own this, our earlier analysis did arrive at a
conclusion.

My earlier analysis was (again) in the (still too long):


http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Sep/0378.html

[[[
[1a]
The Unicode String in an RDF Literal is normalized according
to Unicode Normalization Form C [NFC, NFC-Corrigendum], using
a framework of early uniform normalization.
]]]

This amounts to:
- all RDF syntaxes are constrained to only permit Unicode strings that are
normalized.
- So that a graph with a node labelled with a Unicode string with a
character c followed by a non-spacing cedilla character in it is not an RDF
graph.
- RDF/XML syntax includes this restriction on literals
- N-Triple syntax includes this restriction.
- implementations that read documents in non-unicode characeter sets (e.g.
many XML implementations) need to use a normalizing transcoder when
converting into Unicode.

"Early uniform normalization" is simply another way of saying that. Early
uniform normalization means that it is the original document's author's
responsiblity to not create non-normalized strings.

I could provide some test cases of ill-formed RDF/XML under this proposal.

My understanding of how this differs from requiring an RDF/XML document to
be fully normalized XML is as follows:

A] Fully normalized XML permits the sequence character c, XML comment,
non-spacing cedilla.
  This proposal prohibits that sequence.

B] Within an XML comment fully normalized XML prohibits the sequence
character c, non-spacing cedilla. This proposal does not prohibit this.


I think [A] is a defect with the current concept of fully normalized XML.
Either there should be more acknowledgement that XML documents are read in
different ways depending on quite what sort of XML document it is, or
minimally it should be required that all string values within the XPath node
set are normalized.

I think [B] could be added as an additional requirement on RDF/XML, i.e.
that the XML as XML is fully normalized as per charmod.


I do not believe that this presents implementators with too much work.

The thorough implementator will need:
- normalizing transcoders.
  These should be off-the-shelf components, since in a while all W3C specs
will require their use. (Are any available?)

- ability to detect Unicode strings that are not NFC.
  I thought I had seen some fairly simply open source code to do this.
Anyone have a pointer?



The DPH (less thorough implementor) can:
- ignore the whole issue if they are only interested in a US market, and get
reasonably interoperability.
[This, as I understand it, is one of the goals of early uniform
normalization].



Jeremy

Received on Wednesday, 20 February 2002 08:28:09 UTC