W3C home > Mailing lists > Public > public-rdf-wg@w3.org > November 2011

Re: Re 2: XML literals poll

From: Pat Hayes <phayes@ihmc.us>
Date: Mon, 21 Nov 2011 16:36:12 -0600
Cc: Richard Cyganiak <richard@cyganiak.de>, RDF Working Group WG <public-rdf-wg@w3.org>
Message-Id: <EEDCFD29-617F-417E-AB37-9BF342DD1CD9@ihmc.us>
To: Ivan Herman <ivan@w3.org>
Mine also. Let me turn the question around: is there any case at all for keeping XMLLIteral as having a special status within RDF? Seems to me that if we were designing RDF now this idea would not even be being considered. If it is a 'normal' datatype included in the D-interpretation part of the machinery, then a lot of these issues become a lot less urgent and pressing. 

Pat


On Nov 21, 2011, at 2:29 PM, Ivan Herman wrote:

> Richard, I think there is a missing question: should XML Literals be optional? My answer would be yes...
> 
> Ivan
> 
> ----
> Ivan Herman
> Tel:+31 641044153
> http://www.ivan-herman.net
> 
> 
> 
> On 21 Nov 2011, at 20:32, Richard Cyganiak <richard@cyganiak.de> wrote:
> 
>> Below are six questions on XML literals. Please help the WG get a feeling for the general opinion within the group by answering the questions. Answers in the usual +1/±0/-1 style are appropriate.
>> 
>> Thanks,
>> Richard
>> 
>> 
>> 
>> Q1. Should the specs define a way to compare XML literals based on value?
>> 
>> In other words, in the same way that integers 7 and 007 have the same value, should <foo/> and <foo></foo> be defined as having the same value?
>> 
>> 
>> 
>> Q2. Should the specs say that RDF implementations MUST support value-based comparison?
>> 
>> In other words, assuming the specs define a value space that answers Q1 in the affirmative, is it required that all RDF toolkits implement some sort of canonicalization somewhere in the process?
>> 
>> 
>> 
>> Q3. Should the *lexical* space be in canonical form?
>> 
>> In other words, should
>> <> ex:value "<foo/>"^^rdf:XMLLiteral.
>> <> ex:value "<foo></foo>"^^rdf:XMLLiteral.
>> 
>> result in a graph with one triple (canonicalize) or two (don't canonicalize)? Note that if you answer “two”, then it is unavoidable that round-tripping an XML literal, or storing the same XML literal in two different formats (say, RDF/XML and Turtle) and reading it again, will sometimes result in a different triple (with the same value though).
>> 
>> 
>> 
>> Q4. Should *invalid XML* be allowed in the lexical space?
>> 
>> In other words, should "</bar !!!>"^^rdf:XMLLiteral be ill-typed (just like "AAA"^^xsd:integer) or well-typed (just like "</bar !!!>"^^xsd:string)?
>> 
>> 
>> 
>> Q5. Should the specs say that RDF/XML parsers MUST canonicalize when handling parseType="literal"?
>> 
>> RDF/XML parsers are often implemented on top of an XML parser, and hence they don't have access to a low-level representation of the XML literal, e.g., did it use single or double quotes in the attributes, what order where the attributes in, or how many spaces were between them? If they don't canonicalize, then two different RDF/XML parsers would be pretty much guaranteed to parse the same RDF/XML file into different triples (or even different runs of the same parser over the same file could yield different triples).
>> 
>> 
>> 
>> Q6. Should it be required that producers of XML literals in concrete syntaxes (Turtle, N-Triples, other parseTypes in RDF/XML) canonicalize the literals themselves?
>> 
>> If the lexical space is canonicalized (see Q3), then it means that canonicalization either has to be done by parsers (see Q5), or by content producers.
>> 
>> 
>> 
>> (FWIW, the RDF 2004 design is: Q1: Yes. Q2: Yes. Q3: Yes. Q4: No. Q5: Yes. Q6: Yes.)
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Monday, 21 November 2011 22:36:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:46 GMT