[Dbix-class] RFC: renaming SQL::Routine out of SQL

[Darren Duncan]

P.S. I'm sending this to dbix-class too, since some people whose 
opinions I respect don't appear on the other lists.

------------------

This RFC is an early probe, and is only being sent to 2 discussion 
lists for now, dbi-users and poop-group.  If necessary, I may derive 
a better version later for wider dissemination, based on your 
feedback.

In the course of my rewrite of the Rosetta database access framework 
(started on October 1st), the system has evolved so much that it is 
now based a lot more on relational algrebra than on SQL, and I am now 
doubting that the major component named SQL::Routine should keep that 
name.

To put things in context, the main purpose of "SQL::Routine" right 
now is to define a language, similarly to the purposes of the Perl 6 
Synopsis, but that it also provides objects to store something akin 
to a parse tree of it; I say "akin" because the tree is actually the 
native form; there is no native string version like Perl 6 is. 
Continuing this context, the main purpose of "Rosetta" is to be a 
federated implementation of that language, similarly to what 
Pugs/Parrot do.

This RFC is concerned with whether SQL::Routine should continue with 
its current name or be rebranded into a different name that doesn't 
contain 'SQL' in it, and is otherwise more appropriate to its altered 
direction.

Part of the issue is that the new system is meant to be centered 
around the concept of a "truly relational" database, such as Codd, 
Date, Pascal, Darwen, etc promote, rather than the "sort of but not 
really relational" model of a database that SQL describes.  While it 
is popularly thought that SQL = Relational, there are strong 
arguments from serious database people that say otherwise.

I want to distance my project from the word 'SQL', using the term 
only to indicate something in a similar problem domain to my project, 
also taking examples for the purpose of explanation; I do not want to 
say that my project *is* a SQL model or implementation.

Now, while a lot of influence is taken from the SQL language, various 
database products implementing flavors of it, languages like Tutorial 
D, and even the Perl 6 language itself, and other mathematics, the 
language of my project is my own new language in the end.  It is 
sufficiently different than SQL that it shouldn't have 'SQL' in its 
name, just to not confuse users if nothing else.

At the same time, still focused on serving the interests of both 
portability and practicality, my language still supports all the 
significant concepts of SQL that are frowned upon by "truly 
relational" people, such as nulls and duplicate rows, but you have to 
explicitly indicate that you want to use them, and in the absense of 
that, relations can not contain duplicates or nulls.  Both types of 
behaviour can be mixed; it is the data types that you choose to use 
on a per-container or per-value basis that determine whether those 
are allowed.  The distinct data types in question are implemented 
separately, and the ones not allowing nulls or duplicates will happen 
to be simpler and perform faster, since there is less logical 
complexity to deal with.  So both "truly relational" and "SQL" people 
can have their cake and eat it too.  And porting between the both 
types (and other types) of systems can be accomplished with little 
trouble.

For some details of the new language, see either of the following 
(they are not on CPAN yet):

1. 
http://svn.openfoundry.org/pugs/ext/Rosetta-Incubator/lib/SQL/Routine/Language.pod

2. http://svn.utsl.gen.nz/trunk/Rosetta-Incubator/lib/SQL/Routine/Language.pod

That document is in the process of being written right now, but a 
substantial portion already exists.  By the time you see this RFC, 
more may be done.  See also the DESCRIPTION pod of lib/SQL/Routine.pm 
and lib/Rosetta.pm in either repository.

Now, the documentation currently refers to the language as "the 
SQL::Routine language", but that seems very cumbersome.  What I 
really want to do is come up with some new catchy and/or descriptive 
name for the language that I can use by itself as a noun, and people 
generally know what I'm referring to.  Eg, just as people can say 
"Perl 6" or "SQL" or "Tutorial D" and readers just know that those 
are language names, I want someone to say "<Foo>" and it is fairly 
unambiguous that this is a language name, and not, say, just a module 
name.

The main kind of feedback I need is, what a good *language name* 
would be for what I'm making here.  The new name of the module can be 
determined afterwards, and be derived from the language name.

The name of the language should say "relational" or "relational 
database", but not so much just using those words, since they are too 
generic and are used as adjectives everywhere.  It could just be a 
catchy made up name or acronym too.  Being short is good.  (Note that 
I can't use "Rel" as a name since its already in use by Dave Voorhis' 
project at http://dbappbuilder.sourceforge.net/ .  It shouldn't be 
the same name as any other project either.)

Moreover, I suspect that the renamed module should perhaps be 
reclassified on CPAN to a different category than "string language 
processing"; perhaps it should go where ever PPI is classified, 
though I don't know where that is, or perhaps where PDL is, or 
perhaps under "database interfaces" even though it only defines one 
and doesn't implement it.  (In any event, Rosetta sits under 
"database interfaces" and will reference it.)

Thank you in advance for the feedback.

-- Darren Duncan

P.S. The chosen names would be used for and identical in the perl 5 
and perl 6 versions of this.