<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I will give you a somewhat short answer to that question but we can expand only if necessary.<div class=""><br class=""></div><div class="">**********</div><div class="">True in general for every query language</div><div class="">**********<br class=""><div class=""><br class=""></div><div class="">1. In general I think a “query” language should be functional and compositional.</div><div class="">(besides having a high expressive power, it has other advantages like being able to do data flow analysis</div><div class="">through the function invocations — which is necessary for almost EVERYTHING inside a database,</div><div class=""> from logging to index detection to optimizability)</div><div class=""><br class=""></div><div class="">SQL got only a “little” but of comparability only after decades of existence….for my taste it’s really clunky.</div><div class="">I never remember what I can compose with what — and never understand why not !??</div><div class=""><br class=""></div><div class="">2. In general a query language should have the FLWOR-like  expression  (called it as you like, SELECT-FROM-WHERE</div><div class="">whatever). In mathematics (or theoretical computer science) it is called monoid comprehension. </div><div class=""><br class=""></div><div class="">The more powerful the FLWOR like expression, the more expressive power of the query language.</div><div class=""><br class=""></div><div class="">I think XQuery has the best designed expression of this kind in existence. It’s compositional, elegant, symmetrical.</div><div class="">The semantics is very well defined, and … if you look well… NOWHERE IN THE DEFINITION OF THE SEMANTICS</div><div class="">OF THE FLOWR EXPRESSION THE WORD XML OCCURS.</div><div class=""><br class=""></div><div class="">The FLWOR expression of XQuery is a construct that has NOTHING to do with XML !!</div><div class=""><br class=""></div><div class="">3. In general, a query language is not a query language unless is optimizable.(aka the ability for a compiler to be able to </div><div class="">derive from one syntax many different ways of evaluating the result, some being more optimal then others).</div><div class=""><br class=""></div><div class="">I think during the design of XQuery a HUGE deal of attention was done to the optimizability of the language. The implementations </div><div class="">show that we didn’t get it wrong. Most implementations have decent response time (even though alas, there is no standard benchmark).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">***************</div><div class="">Things that are absolutely necessary for semi-structured query languages</div><div class="">**************</div><div class=""><br class=""></div><div class="">1.Conditionals, typeswitches</div><div class=""><br class=""></div><div class="">In schema-less data, we never know what we’ll find. We HAVE to be able to branch based on what we find in the data while searching.</div><div class=""><br class=""></div><div class="">2. Functions and recursive functions</div><div class=""><br class=""></div><div class="">While dealing with nested, pre-aggregated data, we need to navigate structures on unknown depth, and for this we really need functions</div><div class="">and recursive functions.</div><div class=""><br class=""></div><div class="">3. Error management: try/catch</div><div class=""><br class=""></div><div class="">Even with the best precautions, while dealing with data of unknown structure, we can ALWAYS find unexpected stuff: an integer when we </div><div class="">thought we’ll get a string, and we try to cast it to a date. Hence, an error.</div><div class=""><br class=""></div><div class="">Imagine you processed already 1 million rows, and suddenly one of those rows is “bad”. In the absence of a try/catch the whole result will be an exception</div><div class="">and your hard work on a million rows is lost.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">==========</div><div class=""><br class=""></div><div class="">Now those three things: switches of all kinds, recursive functions and error management change the good old query processing DRAMATICALLY.</div><div class="">(why is that ? Because they make difficult the famous data flow analysis I just talked about — and which is a necessity in any query optimizer).</div><div class=""><br class=""></div><div class="">Relational database optimizers don’t deal with such difficulties, because they didn’t have them.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">That’s a short answer of why XQuery is better for processing semi-structured data then any other alternative out there.</div><div class=""><br class=""></div><div class="">Note: REMARK THAT IN THIS WHOLE EMAIL I NEVER PRONOUNCED THE WORD XML.</div><div class=""><br class=""></div><div class="">XQuery, despite it’s very unfortunate name, is NOT an XML query language (ONLY).</div><div class=""><br class=""></div><div class="">It’s basic principles have nothing to do with XML.</div><div class=""><br class=""></div><div class="">That’s why in JSONiq it was trivial to take out the “/“ navigation, replace it with “.” navigation, replace the node constructors with object</div><div class="">constructors, and here we go.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Best regards</div><div class="">Dana</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 30, 2015, at 10:45 AM, Ihe Onwuka <<a href="mailto:ihe.onwuka@gmail.com" class="">ihe.onwuka@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, May 30, 2015 at 12:42 PM, daniela florescu <span dir="ltr" class=""><<a href="mailto:dflorescu@me.com" target="_blank" class="">dflorescu@me.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Great. Well JSONiq is my tool of choice for dealing with JSON. </div><div class=""><br class=""></div><div class="">Can you provide any insights to the graph database landscape. A conversation on xml-dev with Peter Hunsberger has persuaded me that a dual representation (XML for serving data and graph for running algorithms) is probably what I need but I prefer to have some basis for evaluation before jumping in with any particular product.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Unfortunately I cannot help you here. I tried to keep up with the graph languages, but lost it at some</div></div><div class="">point. Things are moving too fast. </div><div class=""><br class=""></div><div class="">And unlike NoSQL query languages, where the situation is really pathetic, the graph languages and their implementations</div><div class="">are not that bad, I think. So there are reasonable choices...</div></div></blockquote><div class=""><br class=""></div><div class="">Ok back to these NoSql offerings I have a question.</div><div class=""><br class=""></div><div class="">You are always telling these vendors that their products are not databases they are data stores. Now from that and the limited amount i have read (it is difficult to continue reading beyond the point where you know this is not a product you want to use) it sounds like these products are little more than glorified VSAM files.</div><div class=""><br class=""></div><div class="">I get why SQL is not an appropriate basis for a language for these data stores but I don't yet see how we make the leap from XQuery being a language for particular types of semi-structured data to it being the basis of a query language suitable for semi-structured data in principle, unless you are talking in very broad terms about the features such a query language should have and what principles should guide it's design.</div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">P.S. 20 years ago I wrote a paper about a graph language (we thought at that time that semi-stuctured data will necessarily be a graph…)</div><div class=""> which kind of influenced the design of SPARQL.</div><div class=""><a href="http://www.en.pms.ifi.lmu.de/publications/projektarbeiten/Felix.Weigel/xmlindex/material/fernandez97strudel.pdf" target="_blank" class="">http://www.en.pms.ifi.lmu.de/publications/projektarbeiten/Felix.Weigel/xmlindex/material/fernandez97strudel.pdf</a></div><div class=""><br class=""></div><div class="">But of course, this is no help to you, other then intellectual curiosity :-)</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">People who are not intellectually curious end up writing blogs about why you should not do what they did. Then again they also get the kudos of being  invited to give talks about their cock-ups to other people who are not intellectually curious but want to learn from the bitter experience of others.</div><div class=""><br class=""></div><div class="">But  yes i will try and give it a read.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div>
</div></blockquote></div><br class=""></div></div></body></html>