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

Value-based comparison and GML (was: Re: XML literals poll)

From: Richard Cyganiak <richard@cyganiak.de>
Date: Wed, 23 Nov 2011 22:44:44 +0000
Cc: public-rdf-wg@w3.org
Message-Id: <57446197-3BA1-4301-A3C5-55C0770013B5@cyganiak.de>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
Hi Andy,

Thanks for the comments. I have one question below where I didn't understand your response.

On 21 Nov 2011, at 22:37, Andy Seaborne wrote:
> Q0: should XML Literals be optional?
> Yes
> (I'm pulling this out as I see it not as a consequence of Q2 but as a design requirement)

Ok, noted.

>> Q1. Should the specs define a way to compare XML literals based on
>> value?
>> In other words, in the same way that integers 7 and 007 have the
>> same  value, should<foo/> and<foo></foo> be defined as having the same value?
> -1
> A user has worked with GML literals, which some times have 2 or more attributes.  The sorting requirement of exclusive-canonicalization was a surprise to them and meant that putting output from a geospatial database into RDF using ^^rdf:XMLLiteral didn't work.

This seems like an argument that responds to Q6 (Should authors/generators of Turtle documents be expected to produce canonicalized rdf:XMLLiterals?) and not to Q1. From the GML case that you describe, I don't follow how you arrive at opposing infoset/C14N-based comparison for XML literals.

> You could argue that it should not be an XML literal, but it seems more reasonable to make it a derived type of XML literal (it is XML after all) then the canonicalization rules would apply.
> It's a tradeoff.  I favour weaker equality for more usability.

Usability, in my understanding, would be about what is a valid document (that is, what goes into the parser), or what goes into and comes out of an RDF API. Comparing XML literals based on value shouldn't affect that.

So did you respond to Q6 here, or am I misunderstanding your argument?

Received on Wednesday, 23 November 2011 22:45:23 UTC

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