Re: ISSUE-13: History of rdf:XMLLiteral

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