Re: Keeping XMLLiterals unchanged when going through RDFa

Agreed - the canonical version is guaranteed to be same as the lexical form
as far as the parser is concerned.  That's the point of canonicalization.


On Wed, Jun 4, 2014 at 12:35 PM, Gregg Kellogg <gregg@greggkellogg.net>
wrote:

> 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.
>
> Gregg
>
> > Cheers,
> > Reto
>
>
>

Received on Wednesday, 4 June 2014 18:44:20 UTC