Re: Re-opening ISSUE-22 on vendor-specific SQL

On 31 May 2011, at 20:46, David McNeil wrote:
> Although my fear is that most real-world mapping will have some vendor specific SQL in them

I absolutely agree.

> and therefore most real-world mappings will have "no particular behavior" defined.

Well, I see what you mean, but I don't see a good alternative.

I wouldn't want to specify the behaviour of an R2RML engine where all SQL-carrying properties (rr:SQLQuery, rr:table, rr:tableOwner, rr:column, rr:template and so on) can contain opaque blobs. If anyone asked us to nail down the spec, we'd quickly have to give up.

Implementer: “Ok, I'm trying to be conformant. So, what is the semantics of rr:SQLQuery if it's flagged as vendor-specific?”

Me: “You treat it as opaque and pass it to the RDBMS you're connected to. We assume that you get back a tabular result set.”

Implementer: “What about rr:column?”

Me: “It still refers to a column name in the result, like before.”

Implementer: “What characters can rr:column contain?”

Me: “That depends on the SQL dialect. It must be a column that occurs in the query result.”

Implementer: “Is it case-sensitive?”

Me: “Again, that may depend on the SQL dialect.”

Implementer: “So, if the query result has a column with different case, is that an error, or do I use that column's value to generate a triple?”

Me: “It depends on the dialect.”

Implementer: “But I have to implement that one way or the other.”

Me: “You'll have to check the documentation of the RDBMS engine you're connected to, and implement it accordingly. That's the price you pay for supporting other SQL dialects.”

Implementer: “So you mean your so-called specification does not specify it?”

Me: “... sigh ...”


> That seems a bit startling for a spec, but maybe I could get used to it :)

The thing is, implementers will know what to do anyways, it's just impossible for us to write it down normatively in the spec. We could add some handwaving text that explains the intuition of handling vendor-specific SQL in the appropriate way, but I don't see how that's any better than just saying, “We define R2RML for SQL 2008 Core, full stop. You use another dialect, it's up to you to figure out the details.”

Can you think of some words that work better for you than the proposed ones?

Best,
Richard

Received on Tuesday, 31 May 2011 20:58:17 UTC