Comments from Julien Homo - TCs

Hi all

I've fixed the issues Julien found in the TCs [1][2].

However, he/she also pointed out some issues I want to discuss with the group.

Issue/question A
J: My R2RMLTC0009c and R2RMLTC0009d tests fail because mapping was successfull with unamed column on the two dbms : why any columns in the SELECT list derived by projecting an expression like an expression with keyword COUNT must be named ? Is it to conform to Core SQL 2008 ?

B: Because we need to refer to those columns, otherwise there won't be a way to reference those, right? … it's no related to the Core SQL 2008

J: Besides in the second test, an implicit integer datatype is associated with SPORTCOUNT column but this is not the case in your result. A simple cast to string is required for this column ?

B: I've just realized this and fix it in the R2RMLTC0009d, so now it has xsd:integer

Issue/question B
J: R2RMLTC00016e and DirectGraphTC0016 tests fail :  I have to modify SQL input file in order to postgreSQL does not raise a syntax error. Indeed, on the one hand BINARY VARYING is an unknown datatype for postgreSQL (bytea data type allows storage of binary strings, http://www.postgresql.org/docs/9.1/static/datatype-binary.html). 

B: We have to check how to deal with this. AFAIR Nuno has the same problem, does anyone of the group is working with this matter?

J: On the other hand, encoding characters like "\ux2F" instead of "/" are not recognized. Is necessarilystrictly adhere to the syntax of the SQL query to validate this test or these requests can be adapted ?
B: I had to use "\ux2F" because hsqldb (I'm using hsqldb for parsing the SQL scripts) does not support "/" within BINARY VARYING. Does anyone of the group have the same problem with other DBMS?

Issue/question C
J: R2RMLTC0016b and DirectGraphTC0016 : You use canonical RDF lexical form for double datatypes like"80.25E0" but it's "8.025E1" that appears in DirectGraphTC0016. R2RML CR indicates the choice of lexical form is implementation-dependent but my test fails because these results are not homogeneous. Can you confirm this expected result ?
B: It was my mistake, now both (DirectGraph and R2RML) are the same "8.025E1" …. is that ok?

Issue/question D
J: R2RMLTC00016e : IRI built from binary data seem to be not base64 encoded ("<data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P5//6/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==>") contrary to the DirectGraphTC0016 test.
B: Actually the IRIs of the R2RML are the good ones, because the idea of create them was to have data URIs … thoughts? I need to fix the DirectGraph ones.

Thanks in advance and regards

Boris

P.S. I can include the issues/questions on the wiki page for gathering the implementations experiences, what is the URL?

[1] http://www.w3.org/2001/sw/rdb2rdf/test-cases
[2] https://dvcs.w3.org/hg/rdb2rdf-tests/