W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > June 2014

Re: Keeping XMLLiterals unchanged when going through RDFa

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Wed, 4 Jun 2014 10:35:53 -0700
Cc: W3C <public-rdfa-wg@w3.org>
Message-Id: <2D049418-8CAB-4561-98A3-9C99C37794CD@greggkellogg.net>
To: Reto Gmür <reto@apache.org>
On Jun 4, 2014, at 3:25 AM, Reto Gmür <reto@apache.org> wrote:

> Hi,
> I'm writing a browser based editor to edit graphs rendered as RDFa/HTML.
> I encountered the problem that the round-trip via browser changes the value of the XMLLiterals, e.g. a <br/> becomes <br /> (in firefox) or a <br> (in chrome). There seems to be no way to the client library to get the exact original version as the js has only access to the DOM not to the literal source. This of course makes it impossible to update the content using e.g. a SPARQL DELETE/INSERT.
> I though one work around would be to pass the original version in a content attribute. This way the client could read out the exact literal before the editing starts and use this version when sending back the DELETE/INSERT request.
> Unfortunately I noticed that the content node is ignored if the datatype is set to rdf:XMLLiteral. 
> Is there any way to encode an arbitrary XMLLiteral in RDFa so that it remains identical character-by-character when encoding as RDFa and decoding again?

The point of XMLLiteral (and rdf:HTML, which may be more appropriate for you) is that it does not preserve the lexical representation of the values, but that the values are the same, after some form of canonicalization (XML C14-XL for XMLLiteral and coercion to DOM for rdf::HTML). If you really must preserve the lexical representation, then there’s really know way to do this in RDFa without encoding it using HTML escapes, so that it’s treated just as a string literal.

Probably better if your tool didn’t expect the exact lexical form, but allowed for some canonicalization, or always emit canonical XML/HTML.


> Cheers,
> Reto
Received on Wednesday, 4 June 2014 17:36:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:35 UTC