Re: ISSUE-13: History of rdf:XMLLiteral

>  Well then let's make that explicit.

That basically takes us back to something like the first LC design that 
was rejected. Personally I preferred putting the canonicalization in the 
L2V map.
It is quite a pain to specify though, and people didn't like the verbal 
gymnastics required.
(You do end up needing a wrapper element ... yuk yuk yuk, and for 
backward compatibility we will need to add the wrapper to the lexical 
form, apply C14N, then remove the wrapper ...)

A different way of making explicit would be to explicitly state that 
c14n is only required where the app requires comparison.

Although I would tend to agree that there is a valid use case of 
entering XMLLiterals by hand in an TTL file or whatever

Jeremy




On 11/10/2011 2:44 PM, Richard Cyganiak wrote:
> Hi Jeremy,
>
> On 10 Nov 2011, at 22:26, Jeremy Carroll wrote:
>> 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
> Well then let's make that explicit.
>
> Require C14N only as part of the L2V mapping and not in the lexical form, so that the parsers who mess up are actually conforming. This way we might even get a chance to use rdf:XMLLiteral in Turtle, where we currently need to canonicalize *by hand*.
>
> And make rdf:XMLLiteral an optional part of the datatype map (like the XSD types) so that apps who don't need to compare XML values can just treat it as opaque blobs.
>
> As far as I can see, everybody wins.
>
> Best,
> Richard

Received on Thursday, 10 November 2011 23:01:23 UTC