Charmod-Literal from Jeremy Carroll on 2002-04-03 (w3c-rdfcore-wg@w3.org from April 2002) (original) (raw)

Last telecon the charmod literal issue (number 13) collapsed because DanC didn't like the erratum process that was being proposed.

I wanted to have another go basically aiming at a similar resolution, using grey test-cases.

I am using HTML/UTF-8 to try and prevent the funny characters getting munged.

White test case:

RDF/XML

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:eg="http://example.org/"> <rdf:Description rdf:about="http://www.w3.org/TR/2002/WD-charmod-20020220"> <eg:Creator eg:named="Dürst"/>

N-Triple

_:j21411 <http://example.org/named> "D\u00FCrst" . <http://www.w3.org/TR/2002/WD-charmod-20020220> <http://example.org/Creator> _:j21411 .

DaveB: have I encoded the ü correctly?

Black test case 1:

Not RDF/XML <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:eg="http://example.org/">

<rdf:Description rdf:about="http://example.org/adult-content.html"> <eg:Creator eg:named="Dürst"/>

Rationale: the literal value is not in NFC.

Black test case 2

Not RDF/XML

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:eg="http://example.org/">

<rdf:Description rdf:about="http://example.org/adult-content.html"> <eg:Creator eg:named="Dürst"/>

Rationale: the literal value is not in NFC.

Grey test case 1:

Maybe RDF/XML

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:eg="http://example.org/#">

rdf:Description eg:strangëfoo

Corresponding to maybe n-triple

_:j21475 <http://example.org/#strange> "\u0308foo" .

Grey test case 2:

Maybe RDF/XML

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:eg="http://example.org/#">

rdf:Description eg:strangëbar

Corresponding to maybe n-triple

_:j21475 <http://example.org/#strange> "\u0308bar" .

Black test case 3:

Not RDF/XML

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:eg="http://example.org/#">

rdf:Description eg:strange̸foobar

Grey test case 3:

Maybe RDF/XML

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:eg="http://example.org/#">

rdf:Description eg:strange̸foobar

Maybe N-triple

_:j21573 <http://example.org/#strange> "\u0338foobar" .

I propose a) the white test case is legal RDF/XML b) black test cases 1 & 2 are not RDF/XML c) conformant RDF processors may treat the grey test cases 1 and 2 in any of the following fashions:

reject the input with an error message
process the input to produce the given n-triples preferrably with a warning message. d) black test case 3 is not RDF/XML e) grey test case 3 is processed as under (c)

Justifications: a) the literal is in NFC b) the literals are not in NFC c) the literals start with a combining character. implementations conforming with the current version of charmod should reject this. Implementations conforming with earlier versions of charmod would accept this. There does not yet appear to be any consensus concerning strings starting with a combining character. I see it as desirable to:

permit implementations that conform with our best guess at what the charmod req will say (which is the current WD)
not to over-commit to an I18N requirement that lacks stability and consensus d) the whole file is not in NFC and is not legal by any (recent) version of charmod e) ARP cannot distinguish this case from the previous one, but it is similar to (c)

(Note: I believe I have used the N-triple unicode escaping mechanism correctly but I would prefer if we don't get hung up about that aspect).

Brian,

can I suggest we try discussing the test cases this week. If we can agree the behaviour then I can produce text to resolve the issue for another time.

Jeremy