W3C home > Mailing lists > Public > www-rdf-interest@w3.org > October 2001

Re: a new way of thinking about RDF and RDF Schema

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Mon, 22 Oct 2001 11:31:53 +0100
Message-ID: <3BD3F599.1040104@hplb.hpl.hp.com>
To: Brian McBride <bwm@hplb.hpl.hp.com>
CC: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>, www-rdf-interest@w3.org, simeon@research.bell-labs.com

I posted a message today, the text for which got substituted somewhere with 
SPAM.  I attach the text of the original I sent, taken from my sent mail folder, 
below.  I'm investigating the cause of the problem.



Peter F. Patel-Schneider wrote:


--parseType="Literal" is something the RDFCore WG is, err ..., working on, right 
--now.  Its not really clear exactly how to handle this.  Most parsers currently 
--turn it into a Literal, but there is no agreement on exactly what Literal. 
--Other suggestions include generating an RDF representation of the infoset 
--representation of the embedded xml.

-Yes, but how?  Once XML parsing is done you no longer have the original
-bits to be turned into a literal.

Common practise is to turn the sax events back into a string which is a fragment 
of XML.  There is not general agreement on exactly what string to produce, which 
inhibits interoperability.  For example, different parsers may re-order 
attributes into different orders.  There are also problems with namespaces; what 
does one do with the namespaces that are in effect?  Is I also mentioned, there 
is a suggestion to turn a parseType=Literal into an RDF representation of the 
infoset representing the XML fragment.  These are the things the RDFCore WG is 
trying to figure out.

The key question here is, I suspect:

   Can you describe the Literal that you think should be produced.

M&S is not clear on this.

My working hypothesis is that parseType=Literal was invented so that folks could 
include markup in a Literal in an RDF/XML document without having to escape the 
angle brackets etc.  The use cases we have are of that variety.  That is what 
any solution needs to support.

If anyone has any other use cases, I'd love to hear them.

Received on Monday, 22 October 2001 06:36:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:32 UTC