@wallhackio i feel a margo Take coming on this one lol
@aescling that was a desired outcome tbh
@wallhackio @aescling tree based structures are for cowards both JSON and XML are bad for data
XML is better for markup
@wallhackio @aescling JSON is best used for closed APIs with known parameters, where a tight binding exists between the three schemas (see <https://en.wikipedia.org/wiki/Three-schema_approach>)
when these things diverge JSON becomes less and less desirable
@wallhackio @aescling well javascript doesn’t have any native concept of object type so in order to transform JS you have to first identify the type of every object and then call the methods associated with that type
“identify the type of object” can be trivial in the case where every object has a `type` property, but that’s still boilerplate you have to write and most real-world JSON is not this verbose
the end result of all this is that most code for processing JSON is incredibly bespoke
in XML on the other hand, the type of things is obvious (it's the node name), so you can just use a generic recursive descent mechanism with type-specific transforms, and you don’t have to write the first part because that’s XSLT
example JSON:
{ "type": "example"
, "items":
[ { "type": "item"
, "value": 1 }
, { "type": "item"
, "value": 2 } ] }
example XML:
<example>
<items>
<item value="1"/>
<item value="2"/>
</items>
</example>
desired result:
<p>Here are my items: {1}, {2}.</p>
XSLT conversion:
<x:template match="example">
<p>
<x:text>Here are my items: </x:text>
<x:for-each select="items/*"/>
<x:if test="position()!=1">
<x:text>, </x:text>
</x:if>
<x:apply-templates select="."/>
</x:for-each>
<x:text>.</x:text>
</p>
</x:template>
<x:template match="item">
<x:text>{</x:text>
<x:value-of select="@value"/>
<x:text>}</x:text>
</x:template>
conversion from JSON left as an exercise
suppose a new item type is added. with XML/XSLT, this just necessitates adding a single new template to handle it. how much does the code need to change to accommodate this with JSON?