W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > May 2003

Re: Change in definition of RDF literals

From: Graham Klyne <gk@ninebynine.org>
Date: Mon, 19 May 2003 18:50:37 +0100
Message-Id: <>
To: Martin Duerst <duerst@w3.org>, "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
Cc: <w3c-rdfcore-wg@w3.org>

At 08:38 19/05/03 -0400, Martin Duerst wrote:
>I think one way to see it is that the underlying problem is the use
>of a datatype of rdf:XMLLiteral for parseType='Literal' is rather
>artificial. When I read that for the first time, I thought that it
>might be nice to allow XML Schema complex types there, which
>would allow validation of the contents, and would bring simple
>types and complex types closer together.
>The alternative solution is to not treat parseType='Literal' as
>a type at all, but as something separate, as a basic literal in
>and by itself. One way to go would be to treat all literals as
>being XML, with the simple case just having no markup. The
>N-triples notation then would maybe just use some elements
>of XML syntax, such as &amp; and &lt;. Just an idea.

On reflection, I think this last idea is a logical step on from the 
decision we reached last Friday, in that it removes the special-case 
datatype, which I think is a further useful simplification.  I think we 
were forced to consider XML literals separately from ordinary literals when 
we were trying to accommodate the namespace issues, but having dropped that 
idea I think distinguishing XML may be no longer needed.

parseType="Literal" then becomes a pure syntactic device to prevent the 
enclosed literal from being interpreted as RDF, which to my mind is far 
closer to the form of literals that I understood to be presented in the 
original RDF M&S.  Non-XML serializations of RDF simply don't have to be 
aware of XML literals, which I think is a Good Thing.


Graham Klyne
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
Received on Monday, 19 May 2003 13:57:31 UTC

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