W3C home > Mailing lists > Public > public-rdf-wg@w3.org > November 2011

Re: ISSUE-13: History of rdf:XMLLiteral

From: Ian Davis <ian.davis@talis.com>
Date: Thu, 10 Nov 2011 22:37:59 +0000
Message-ID: <CAAiX05F=MGCmRot1PNngC1fmwmCOAELbBxPgbL=g9aHfxcEzkQ@mail.gmail.com>
To: Jeremy Carroll <jeremy@topquadrant.com>
Cc: Richard Cyganiak <richard@cyganiak.de>, RDF Working Group WG <public-rdf-wg@w3.org>, Andy Seaborne <andy.seaborne@epimorphics.com>, Ivan Herman <ivan@w3.org>
On 10 Nov 2011 22:27, "Jeremy Carroll" <jeremy@topquadrant.com> wrote:
> 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

What about merging graphs. Comparison is required to eliminate duplicate

> Jeremy
Received on Thursday, 10 November 2011 22:38:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:10 UTC