W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2011

Re: CSV/TSV results test cases and suggested adaption of JSON results test cases

From: Axel Polleres <axel.polleres@deri.org>
Date: Wed, 10 Aug 2011 10:07:49 +0200
Cc: "SPARQL Working Group" <public-rdf-dawg@w3.org>
Message-Id: <FAA33FD0-AEBC-4531-96BE-388602D0CD28@deri.org>
To: "Gregory Williams" <greg@evilfunhouse.com>

On 9 Aug 2011, at 17:23, Gregory Williams wrote:

> On Aug 9, 2011, at 2:14 AM, Axel Polleres wrote:
> > I solved that by separating the base cases and the corner cases in two different data files now: data.ttl and data2.ttl
> > data.ttl is being used for test cases
> >  :csv01,
> >  :tsv01,
> >  :csv02,
> >  :tsv02,
> > and data2.ttl is being used for test cases
> >  :csv03,
> >  :tsv03,
> >
> > Please check. Given that those test case are ok, I think we have good coverage now.
> I'm mostly happy with the 01 and 02 tests. csv03 still has a c14n problem ("1"^^xsd:decimal). Can we change that like with did with "5.5"?

Well, I deliberately isolated that in a separate test case collecting more "corner cases" than in 01 and 02 , but I still think we shouldn't throw it away, should we? It is a valid test case in the end, isn't it? An alternative would be to even further isolate this particular line into a separate test case 04 and mark it with a comment, saying that engines that do datatype c14n might not pass this one.
Would that sound ok? Any other results in 03 that appear tricky/problematic?

> I also noticed what looks like bad serialized data in csvtsv01.csv and csvtsv02.csv. I think the following strings are meant to be bnodes:

> 442542ca:131ad170ba3:-7ffe
> -78f9575f:131ad16be8d:-7ffe

Indeed, true. (I am afraid that was a bug I had overlooked when I compiled those.

> I've committed new versions with these replaced with _:a.

Perfect, thanks!

> thanks,
> .greg
Received on Wednesday, 10 August 2011 08:08:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:04 UTC