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

Hmmm, re-thinking that, this is indeed an interesting issue.

If I change the lexical form from 5 to 5.5 then in the tsv answer (csvtsv01.tsv, csvtsv02.tsv) I should get 

5.5

instead of 

"5.5"^^<http://www.w3.org/2001/XMLSchema#decimal>

right?

That would add a new aspect to the test case on the one hand, as the spec says "The abbreviated forms for numbers (XSD integers, decimals and doubles) SHOULD be used." 

On the other hand, that kind of misses another point that I wanted to have in that test case, i.e. that I wanted to force 
a datatype URI (different from xsd:string) being in the output tsv.

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.

As for canonicalisation, do we need more test cases elsewhere on top of that?

best,
Axel


On 9 Aug 2011, at 00:28, Gregory Williams wrote:

> On Aug 7, 2011, at 5:10 PM, Axel Polleres wrote:
> 
> > Hi Greg,
> >
> > My focus was not on the aspect of datatype canonicalisation, but just on using an
> > explicit datatype... So, I'd be totally fine in changing this to e.g.
> >
> > s/"5"^^xsd:decimal/"5.5"^^xsd:decimal
> >
> > would that be ok for you?
> > Or shall we keep and mark this test case "as is"?
> > Or both?
> 
> I believe that would be OK for me. And probably makes this a non-issue for most implementations (even if the underlying challenge of testing with possible c14n still remains).
> 
> thanks,
> .greg
> 
> 
>

Received on Tuesday, 9 August 2011 06:14:57 UTC