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

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