<story><title>A Journey building a fast JSON parser and full JSONPath</title><url>https://github.com/ohler55/ojg/blob/develop/design.md</url></story><parent_chain><item><author>strken</author><text>People say this, and yet XML&amp;#x27;s origins as a markup language make it baffling as a data format. No sane human being should choose a data format with such confusion between properties that no user knows whether to go with&lt;p&gt;&lt;pre&gt;&lt;code&gt;    &amp;lt;Foo&amp;gt;
      &amp;lt;Shininess&amp;gt;HIGH&amp;lt;&amp;#x2F;Shininess&amp;gt;
      &amp;lt;Luck&amp;gt;7&amp;lt;&amp;#x2F;Luck&amp;gt;
    &amp;lt;&amp;#x2F;Foo&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
or&lt;p&gt;&lt;pre&gt;&lt;code&gt;    &amp;lt;Foo shininess=&amp;quot;HIGH&amp;quot; luck=&amp;quot;7&amp;quot; &amp;#x2F;&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
and yet countless thousands decided to do just that, for reasons that are totally inexplicable to me.&lt;p&gt;Obviously as a markup language this is fine; as a &lt;i&gt;data format&lt;/i&gt; it&amp;#x27;s bizarre, since the division between attribute vs child doesn&amp;#x27;t match most in-memory data structures.</text></item><item><author>baz00</author><text>Is JSON XML yet? Nearly!&lt;p&gt;I’m going to invent Baz’s 11th law of computing here: any data format that isn’t XML will evolve into a badly specified version of XML over time.</text></item></parent_chain><comment><author>Communitivity</author><text>I haven&amp;#x27;t used XML is a long while, but there was a trick I had when I designed schemas, back when I did use XML all the time. Use an attribute if the data is a primitive String, number, or boolean. Break into multiple attributes if the data is structured but has only one level and has few children. Otherwise use an element. The three rules are simple, but produce schemas easy to read, easy to maintain, and easy to implement against. One code smell is if you start winding up with tons of attributes on one element. That may mean you should break the logical concept that element represents into multiple concepts, have those concepts be nested elements, each with its related attributes.</text></comment>
<story><title>A Journey building a fast JSON parser and full JSONPath</title><url>https://github.com/ohler55/ojg/blob/develop/design.md</url></story><parent_chain><item><author>strken</author><text>People say this, and yet XML&amp;#x27;s origins as a markup language make it baffling as a data format. No sane human being should choose a data format with such confusion between properties that no user knows whether to go with&lt;p&gt;&lt;pre&gt;&lt;code&gt;    &amp;lt;Foo&amp;gt;
      &amp;lt;Shininess&amp;gt;HIGH&amp;lt;&amp;#x2F;Shininess&amp;gt;
      &amp;lt;Luck&amp;gt;7&amp;lt;&amp;#x2F;Luck&amp;gt;
    &amp;lt;&amp;#x2F;Foo&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
or&lt;p&gt;&lt;pre&gt;&lt;code&gt;    &amp;lt;Foo shininess=&amp;quot;HIGH&amp;quot; luck=&amp;quot;7&amp;quot; &amp;#x2F;&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
and yet countless thousands decided to do just that, for reasons that are totally inexplicable to me.&lt;p&gt;Obviously as a markup language this is fine; as a &lt;i&gt;data format&lt;/i&gt; it&amp;#x27;s bizarre, since the division between attribute vs child doesn&amp;#x27;t match most in-memory data structures.</text></item><item><author>baz00</author><text>Is JSON XML yet? Nearly!&lt;p&gt;I’m going to invent Baz’s 11th law of computing here: any data format that isn’t XML will evolve into a badly specified version of XML over time.</text></item></parent_chain><comment><author>tannhaeuser</author><text>I&amp;#x27;m not disagreeing but the reason XML was used as data format is that it has native support in browsers (remember XML was created as a simplified SGML subset for eventually replacing HTML), the idea being that you can display service payloads via simple stylesheet applications or element replacement&amp;#x2F;decoration rather than having to rely on JavaScript or other Turing-complete environment for arbitrary scripting which was seen as having no place as a central technique in classic document-oriented browsing.&lt;p&gt;JSON became only popular because of similar opportunistic effects (ie being already part of the stack via eval()). If you look at how typical non-JS backends such as Java or .net deal with service request&amp;#x2F;response data, there&amp;#x27;s absolutely no advantage for either JSON or XML - both are represented as class&amp;#x2F;structure and (de-)serialized via binding frameworks and annotations.</text></comment>