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

Re: ISSUE-13: History of rdf:XMLLiteral

From: Jeremy Carroll <jeremy@topquadrant.com>
Date: Thu, 10 Nov 2011 14:26:28 -0800
Message-ID: <4EBC4F94.6040009@topquadrant.com>
To: Richard Cyganiak <richard@cyganiak.de>
CC: Ivan Herman <ivan@w3.org>, Andy Seaborne <andy.seaborne@epimorphics.com>, RDF Working Group WG <public-rdf-wg@w3.org>

I am not sure exactly which part of this thread I am responding to, so I 
am starting afresh ....

I think Richard is seeing the XMLLiterals as harder than they need be.
The design is intended to be such that many RDF processors can behave 
conformantly without doing canonicalization at all.

I think Richard was fairly accurate in his summary of the first LC 
design - the goal being that

<e a="foo"></e>


<e       a='foo'/>

should be the same as XML Literals, because, well, they are the same.
Also for an RDF/XML parser built on top of SAX or DOM, they really are 
the same.

Now, if you need to *compare* two XMLLiterals, then the C14N step is 
required. But it is not required for any other operation, and many apps 
do not need to compare, hence they can behave conformantly, as if they 
had canonicalized XMLLiterals on input, even though they do not.

I suspect this is where Charles is coming from - the 2004 specs do 
actually make it quite easy. An RDF/XML parser should do the C14N step, 
it is not that hard, and so many do. And for a lot of purposes, even if 
you mess up on the C14N step it does not matter so much, because the 
sort of app that does a lot of comparisons is typically logic heavy, and 
does not use XML Literals, whereas the sort of app that uses XML 
Literals is web processing heavy, and isn't very logical, and often 
doesn't do much comparison

Received on Thursday, 10 November 2011 22:27:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:02 UTC