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

Re: XML literals

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 8 Aug 2003 16:28:59 +0300
Message-ID: <002a01c35db1$15bc91a0$3a0ca20a@NOE.Nokia.com>
To: "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>, <w3c-rdfcore-wg@w3.org>
Cc: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>

----- Original Message ----- 
From: "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>
To: <w3c-rdfcore-wg@w3.org>
Cc: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Sent: 08 August, 2003 15:34
Subject: RE: XML literals

> I support Pat's proposal (credited to Peter).
> However, I would like to detail the small amendment that Pat alluded to in:
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Aug/0021.html
> [[
> but can  be thought of as the Xpath nodeset
> ]]

I think it is more correct to have a value space containing Infosets.

Most XML specs define mappings from Infosets to various structures,
such as DOM trees, XPath nodesets, etc. Having values as Infosets
takes a more neutral and general position regarding what XML literals

The failure of the Infoset spec to define a comparison function
can be addressed by us, when defining *our* datatype. By limiting
the L2V mapping to a 1:1 correspondence between lexical and value
spaces, we define an implicit, but sufficient, equality comparison
for members of the value space of rdfs:XMLLiteral based on equality
comparison of their lexical forms.

Choosing XPath nodesets as values seems to be just as syntactically
oriented as just using canonicalized serializations as values.

> One final point is that it is an XPath nodeset, rather than an infoset,
> because C14N works on the nodeset not the infoset.

But could we not still state that the value space consists of 
Infosets, and the L2V mapping is from canonical octet sequence
to nodeset to infoset, and visa versa?

If it can be finessed, I think we are in a better position
having a value space of infosets.

Received on Friday, 8 August 2003 09:30:09 UTC

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