W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > September 2001

RE: 2001-09-07#5 - literal problem

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Thu, 13 Sep 2001 15:00:50 +0100
To: <w3c-rdfcore-wg@w3.org>
Message-ID: <JAEBJCLMIFLKLOJGMELDEECLCCAA.jjc@hplb.hpl.hp.com>

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="..."
   <rdf:value rdf:parseType="Literal">
      <!-- A comment to add to the confusion. -->
      <ns:tag attr1="v1"  attr2="ns:v2"/>

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

Received on Thursday, 13 September 2001 10:02:01 UTC

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