FYI, one of the main goals of the Muldis D language is to be an "open source SQL
standard". It is intended to satisfy both relational and NoSQL folks, and
predates UnQL significantly.
Muldis D has always been published openly and is comprehensive enough to cover
anything that SQL does, and anyone is welcome to improve it.
Moreover, this standard has built-in resilience against "embrace, extend and
extinguish" by including explicit versioning with authorities (Perl 6 inspired
that feature), so that if anyone forks the language, it is possible for the
different versions to be easily distinguishable and non-conflicting, and in a
more benign respect it is designed to be extensible so DBMSs can be free to
evolve under it, adding unique features, while not causing compatibility
conflicts with other DBMSs in the process.
Note that I have fallen behind in specifying a number of intended significant
design improvements/simplifications to the spec proper, though much of this is
hashed out in the laundry list TODO_DRAFT file in github.
-- Darren Duncan
Joe Abbate wrote:
> On 09/19/2011 12:40 PM, Christopher Browne wrote:
>> On Mon, Sep 19, 2011 at 12:20 PM, David Fetter <david@fetter.org> wrote:
>> Actually, I think it *is* a bad idea, as it would require construction
>> from whole cloth of kinds of mostly political infrastructure that we
>> don't have, as a community and aren't necessarily notably competent to
>> construct.
>>
>> The nearest sort of thing that *could* conceivably be sensible would
>> be to participate in UnQL
>> <http://www.unqlspec.org/display/UnQL/Home>. That's early enough in
>> its process that it's likely somewhat guidable, and, with the
>> popularity of NoSQL, being at the "ground breaking" of a common query
>> language to access that would likely be useful to us.
>>
>> If we wanted to start a new standards process, I imagine it would best
>> involve embracing "truly relational," stepping back to PostQUEL, and
>> promoting a standard based on something off more in that direction.
>
> If I were looking for something "truly relational" I wouldn't go towards
> JSON or NoSQL, I'd go with something like Dee
> (http://www.quicksort.co.uk/ ) which IIRC were interested in building a
> PostgreSQL inteface.
>
>> As much as that might sound like a terrible idea, trying to "take
>> over" SQL by forking it strikes me as a much *worse* idea.
>
> My intention was not to "take over" anything. I only think it may be
> useful to discuss SQL features, informally or otherwise, with other open
> source "competitors" such as SQLite, MySQL (brethren), Firebird, etc.,
> and Josh, having been close to the MySQL camp (even physically, from
> what I recall :-) is possibly well suited to start that discussion.
>
> Joe
>