- From: Jeremy Carroll <jeremy@topquadrant.com>
- Date: Thu, 10 Nov 2011 14:26:28 -0800
- 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> and <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 Jeremy
Received on Thursday, 10 November 2011 22:27:01 UTC