<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=""><div><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"><br class=""></blockquote></div><br class=""></div><div class="gmail_extra">Well I have no particular beef with the format itself other than the lack of tools. Now that we have JSONiq I am less bothered about that (assuming one has the opportunity to use it). <br class=""></div></div></div></blockquote><div><br class=""></div>Well, JSONiq is only implemented by Zorba (and another implementation in IBM middle tier).</div><div><br class=""></div><div>And Zorba is a dead piece of code.</div><div><br class=""></div><div>So, having “JSONiq” as a specification…...doesn’t mean much, isn’t it ? Unless is adopted by other XQuery processors.</div><div>(which I cross fingers they will do…)</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra">I agree with your ideals (1 and 2 above) too but it should be evident from the sociology of the JSON community that these things are not going to happen. </div></div></div></blockquote><div><br class=""></div><div>Well… nope. Not clear at all. </div><div><br class=""></div><div>I started working on query languages for XML in 1996. </div><div><br class=""></div><div>Same as now, the whole industry was for using SQL for querying XML — including ME, I had </div><div>a system running, a bunch of PhD students working on that, etc.</div><div><br class=""></div><div>The decision of the W3C NOT to use SQL for that purpose was taken in 2001. </div><div><br class=""></div><div>5 years later. You know how many query languages have been proposed during those 5 years ?</div><div>Tons: UnQL, XML-QL, etc, etc.</div><div><br class=""></div><div>Those things need TIME. </div><div><br class=""></div><div>People need to try SQL first, before they realize it’s a dead end. </div><div><br class=""></div><div>MarkLogic needs to try Javascript on the server side, before realizes that’s a dead end.</div><div><br class=""></div><div>The industry moves MUCH, MUCH slower that one can expect.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">You have people putting stuff in JSON databases without thinking how are we going to get it out and coming up with half-assed solutions for doing so. This is not progress and this is not good.<br class=""></div><div class="gmail_extra"><br class=""></div></div></div></blockquote></div><br class=""><div class="">Again, patience is golden :-)</div><div class=""><br class=""></div><div class="">There will be tons of those half baked solutions (MongoDB’s JSON query language, CouchDB’s..), before people realize that this</div><div class=""> is not going anywhere….some of those databases will be acquired, never to be seen again, them or their query languages….etc.</div><div class=""><br class=""></div><div class="">===============</div><div class=""><br class=""></div><div class="">Honestly, I give it 5 years for the JSON query languages to stabilize. 2020 would be my estimate. Even later if there is a database bubble crash in the</div><div class="">meantime.</div><div class=""><br class=""></div><div class="">Best</div><div class="">Dana</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></body></html>