Revisiting ISSUE-29 (implicit or explicit conversion to strings)

http://www.w3.org/2001/sw/rdb2rdf/track/issues/29
Require blank node and IRI identifier expressions to produce strings

This is currently in "Pending review", awaiting completion of an action to update the spec.

I think however that the problem discussed in this issue is more generic than we initially thought, and that we should revisit the issue.

The problem occurs when a non-string column is used in a context that requires a string:
1. with an rr:column that has rr:termtype "IRI" or "BlankNode"
2. with an rr:column that has rr:language defined
3. with an rr:column that has rr:datatype xsd:string
4. in an rr:template

We have a RESOLUTION that the first case is forbidden. So, the mapping author has to explicitly convert the non-string column to a string in the SQL query.

We could simply extend this RESOLUTION to cover the other three cases as well.

But I believe that in particular for the fourth case, this is highly undesirable, because the whole point of rr:template is that it allows a quick and convenient construction of strings from (often non-string) primary key values, and this often makes it possible to use the base table without making a query-based logical table.

So I'd suggest the use of an implicit string conversion for the fourth case.

But if we use this mechanism for the fourth case, then we can just as well use the same mechanism for the other three cases as well...

How do implicit type conversions work in SQL? SQL has the CAST expression, which can be used to convert between SQL datatypes. Whenever an implicit type conversion is necessary, the result is defined to be the same as using an explicit cast specificatin.

CAST to a string is specified pretty much as one would expect. It defines canonical forms for numbers, datetimes, intervals and booleans. Casting to string is an error for binary datatypes, row types, and reference types. I didn't check what's up with user-defined types.

So,

[[
PROPOSAL: Undo the previous resolution on ISSUE-29, and resolve the issue by stating that conversion to string is done implicitly in any context where a string value is required, and is done according to the rules for SQL's CAST expression. Columns whose type cannot be CAST to string MUST NOT be used in a context that requires a string.
]]

Received on Tuesday, 5 July 2011 14:52:39 UTC