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

Re: XML literals

From: pat hayes <phayes@ihmc.us>
Date: Wed, 13 Aug 2003 22:34:18 -0700
Message-Id: <p06001a0bbb60cd23957f@[]>
To: Graham Klyne <gk@ninebynine.org>
Cc: w3c-rdfcore-wg@w3.org

>While I have sympathy for the approach 
>suggested, I fear it moves even further away 
>from what Martin/I18N seem to be asking for, 
>which is that XML literals and text are more 
>like each other, not less.

I don't think it makes any difference at all to that issue.

But in any case, we cannot go in two opposite 
directions at the same time.  Datatypes values 
are NOT like text.  We could treat XML literals 
much more like text, but that would require us to 
not treat rdf:XMLliteral as a datatype.  The WG 
seems to be unwilling to go in that direction. As 
long as XML literals are treated as typed 
literals they are not being thought of as text. 
If the result disappoints i18n, and if we feel 
that this is the way RDF should go, then we must 
simply decide to disappoint them. If we wish to 
accede to their demands, then we must choose some 
other way to handle XML literals. I no longer 
greatly care which we choose, but I do care that 
we do not spend the next 20 years vacillating one 
way and then the other, trying to keep everyone 
happy. It is IMPOSSIBLE to keep everyone happy.


>At 22:41 31/07/03 -0500, pat hayes wrote:
>>I am completely sick of all these debates about 
>>XML literals. Allow me to suggest a possible 
>>solution, along the lines suggested by Peter, 
>>which will serve to resolve them without making 
>>any substantial changes to the current RDF 
>>design and to everyone's general satisfaction. 
>>This is a wording change to the Concepts 
>>document; I do not believe it amounts to any 
>>real change in our current design, and may be 
>>easier to follow.
>>1. Concepts section 5.1 modified as follows (change starts at ***)
>>Such content is indicated in an RDF graph using 
>>a typed literal  whose datatype is a special 
>>built-in datatype rdf:XMLLiteral ,  defined as 
>>A URI reference for identifying this datatype
>>is http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral .
>>The lexical space is the set of all strings which:
>>are well-balanced, self-contained XML data [ XML ];
>>correspond to exclusive Canonical XML (with 
>>comments, with empty InclusiveNamespaces 
>>PrefixList )[XML-XC14N] ;
>>when embedded between an arbitrary XML start 
>>tag and an end tag form a document conforming 
>>to XML Namespaces [XML-NS]
>>The value space is some set of entities, called XML values, which is:
>>disjoint from the lexical space
>>disjoint from the value space of any XML schema datatype (refer XSD)
>>disjoint from the set of Unicode character strings (refer Unicode)
>>in 1:1 correspondence with the lexical space.
>>The exact nature of XML values is not specified.
>>The lexical-to-value mapping is a 1:1 mapping 
>>from the lexical space onto the value space. 
>>The value of the lexical-to-value mapping
>>The only change to the semantics document then 
>>needed is to change 'XML data' --> 'XML value' 
>>in the second RDF condition, which I have now 
>>done as an editorial change in any case..
>>PS. Peter, I have also fixed the XML range 
>>inconsistency bug, noted in the change log, and 
>>updated the links to refer to the latest 
>>archived editor's draft of Concepts 
>>, dated 28 July
>>IHMC    (850)434 8903 or (650)494 3973   home
>>40 South Alcaniz St.    (850)202 4416   office
>>Pensacola                       (850)202 4440   fax
>>FL 32501                        (850)291 0667    cell
>>phayes@ihmc.us       http://www.ihmc.us/users/phayes
>Graham Klyne          _________
>GK@ninebynine.org  ___|_o_o_o_|_
>                    \____________/
>(nb Helva)       ~~~~~~~~~~~~~~~~~~   @Cliveden, River Thames

IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes
Received on Thursday, 14 August 2003 01:34:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:54:07 UTC