- From: Axel Polleres <axel.polleres@deri.org>
- Date: Wed, 10 Aug 2011 10:07:49 +0200
- To: "Gregory Williams" <greg@evilfunhouse.com>
- Cc: "SPARQL Working Group" <public-rdf-dawg@w3.org>
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!
Axel
>
> thanks,
> .greg
>
>
Received on Wednesday, 10 August 2011 08:08:17 UTC