<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 17, 2015 at 8:49 AM, Michael Kay <span dir="ltr"><<a href="mailto:mike@saxonica.com" target="_blank">mike@saxonica.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>><br>
> But you can pretty much model the semantic equivalent of JSON data without having to use a Schema, namespace, PI or any  traverse any other of these treacherous terrains. Call it XML the Good Parts (Hmmmm where did I get that idea from). JSON is a very expensive over-reaction. There was no need to invent another format and then make in non-interoperable with XML.<br>
><br>
><br>
<br>
</span>Actually, I don’t agree. The cost of doing simple things with XML, like configuration files, is far too high (because of all the other things it is capable of that you don’t need for such cases) and there was a very real need for something simpler for that kind of application.</blockquote><div><br></div><div>But that is not the same as saying that the replacement of XML with JSON as a format for generic data interchange was warranted, and making it not interoperable with XML was spectacularly short sighted. Now true  that probably wasn't the intended use case. Sadly the lack of interoperability and the consequent inability to deploy a common set of tools is probably seen as a virtue in that community. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Restricting yourself to a subset of XML doesn’t greatly reduce the cost of writing code to process it, you still have to use the same APIs. <br><span><font color="#888888"><br></font></span></blockquote><div><br></div><div>When they are done implementing everything with JSON they will find they will have something that will look just like XML, have most if not all of it's atttendant overheads but be even more expensive as it will have been re-implemented from scratch.</div><div><br></div><div>I'm just waiting for the next straight faced instalment.</div><div><br></div><div>What NOSQL needs now is a transformation language.</div></div><br></div></div>