<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 23, 2015 at 1:16 PM, daniela florescu <span dir="ltr"><<a href="mailto:dflorescu@me.com" target="_blank">dflorescu@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br></div></div>
What WILL convince them though is a strong use case, a vertical where tons of money can be made.<br>
<br>
Think AI/machine learning. For how many decades those guys were working in their corner, ignored and<br>
humored ……until SUDDENLY, Google realized that they can make LOTS OF MONEY with their work !?<br>
<br>
What XQuery or JSONiq need right now are strong use cases. Stuff that can be done with XQuery or JSONiq, but cannot<br>
be done otherwise.<br>
<br></blockquote><div><br></div><div>I think what helps with machine learning is that it is not dragged down by being something everybody thinks they can or should do, so progress is not inhibited.</div><div><br></div><div>The use case for XQuery and JSONiq is there but it is being blocked by a belief that SQL++ or N1QL or whatever will satisfice.</div><div><br></div><div>Look to history. How did relational databases supplant CODASYL. Firstly the biggest fish in the pond IBM had a product and backed the technology to the hilt. Then there was a sustained and successful campaign initiated by Codd and Date but grew momentum to differentiate between a proper relational database and a database that just had a relational veneer. </div><div><br></div><div>The former is out of the hands of the XQuery community, the latter isn't. Half the problem is there isn't a consensus on what a query language should be able to do. So formulate the equivalent of Codd's 12 rules for a modern day query language such that each one is  aligned to a discernible benefit i.e this is what you are missing if your language doesn't do this and can be relatively easily verified.</div><div><br></div><div><div>We don't at this point know whether these SQL variants will turn out to be the equivalent of a modern day object oriented Cobol, because right now  their users aren't given reason to question their capabilities and sound of those that would is drowned out by the propaganda deluge.</div></div><div><br></div><div>Daniela you've already started this with contributions to the list but it needs to be fleshed out somewhat e.g composability, what are you missing in practical terms if your language is not composable and how would you demonstrate this property/benefit in a manner that can be critically assessed.</div><div><br></div><div>If you can get vendors to assess their offerings by the criteria defined then half the battle is won.</div><div><br></div><div><br></div><div><br></div></div></div></div>