- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Thu, 13 Sep 2001 15:00:50 +0100
- To: <w3c-rdfcore-wg@w3.org>
I wrote:
> + Does the WG agree that the new specs should descibe a specific Unicode
> string to be delivered by rdf:parseType="Literal"?
e.g. which ntriples doc corresponds to
<rdf:RDF xmlns:rdf="..."
xmlns:ns="http://example.org/">
<rdf:Description>
<rdf:value rdf:parseType="Literal">
<!-- A comment to add to the confusion. -->
<ns:tag attr1="v1" attr2="ns:v2"/>
</rdf:value>
</rdf:RDF>
In our discussions we noted:
- M&S is deliberately vague about quite what unicode string corresponds to
the "well-formed" XML [fragment].
- Particular problems are exhibited by XML fragments with non-local effects
(e.g. namespaces, character or entity references)
- In practive the user community is not crying out for a fix. This vagueness
is a theoretical defect with the specs.
- We expect current conforming implementations to represent
rdf:parseType="Literal" values with different strings (different from one
implementation to the next).
- Mandating any specific string value will probably break all
implementations.
- It is desirable to not prohibit old implementations but allow them as a
"lower" quality implementation.
- One way of having two quality-of-service for literals would be to have a
new parseType e.g.
rdf:parseType="Canonical" that forces the use of XML Canonicalization. This
would then be optional.
- rdf:parseType="Canonical" is feature creep and hence out-of-scope.
So maybe, we need to express some words that capture a minimum level of
conformance that is intended to make almost all implementations legal; and
then in the primer we note to document creators that lots of XML Fragments
are likely to be problematic and non-portable.
Jeremy
Received on Thursday, 13 September 2001 10:02:01 UTC