W3C home > Mailing lists > Public > public-rdf-comments@w3.org > April 2013

Re: normalization issues with Turtle spec tests

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Sun, 07 Apr 2013 13:27:31 +0100
Message-ID: <51616633.10002@epimorphics.com>
To: public-rdf-comments@w3.org


On 07/04/13 07:46, Ruben Verborgh wrote:
> Dear Eric,
>
>> The tests are enforcing checking that the term generaged from e.g. '"+1"^^xsd:integer' is distinct from '1' (which is the same as '"1"^^xsd:integer').
>>   https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#dfn-literal-equality
>> This might be an opportunity to comment out some code.
>
> 1) Do you perhaps know the reason for this choice—and has this changed somewhere along the way?
> If I take
> @prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
>      <a> <b> "1"^^xsd:integer.
>      <a> <b> "+1"^^xsd:integer.
>      <a> <b> "0001"^^xsd:integer.
> and put it through cwm, I get
>      <a>     <b> 1,
>                  1,
>                  1 .
> and if I put that again through cwm, I get
>      <a>     <b> 1 .
> However, does the section you point to means this changed so that '"1"^^xsd:integer’ and the others are no longer equivalent to ‘1’?

What is going on is more than just parsing.  Triples are generated and 
then stored. then tested.

The Turtle test suite is focusing specifically on parsing because the 
Turtle parsing algorithm is about the conversion of UTF-8 bytes to RDF 
abstract syntax.

The literal equality Eric refers to is at the most basic RDF abstract 
syntax.  By having value-based equality - which can be done by 
canonicalising in parsing (sort of - need to consider XSD derived types) 
- is going beyond this basic level.

It might be worth annotating the test manifest to indicate the assumptions.

The thing that has changed is the fact there is an extensive test suite. 
  All this is the same for RDF/XML.

	Andy
Received on Sunday, 7 April 2013 12:28:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:59:32 UTC