3 ms·
An advantage of names in end tags is human readability. Consider this XML fragment: <a>12<b>34<c>56<d>78<e>90</e></d></c></b></a> Appending something to the
by erlehmann_ 10y ago
An advantage of names in end tags is human readability. Consider this XML fragment:
<a>12<b>34<c>56<d>78<e>90</e></d></c></b></a>
Appending something to the end of the d element is easy, since one can just search for its end tag. In JSON and other formats that only have one single character at the end, one has to count brackets or parentheses for this purpose:
(12(34(56(78(90)))))
- mikeash 10y agoIf they're all <a> then you're back to square one. JSON solves this with indentation, pretty printing, and using paired symbols that most conpetent editors can automatically balance. This solves the homogeneous case too. Incidentally, XML can benefit from the first two, and many editors balance tags, so you can get the same thing there.
- erlehmann_ 10y agoIt is rare in real-world XML that elements have children with the same type. Do you have a (non-divitis) example where the tags are all the same?
- lmm 10y agoIt happens with any tree structure. E.g. I used to work on a system that managed reinsurance contracts and represented them as trees of contracts.
- erlehmann_ 10y agoDid the elements often have immediate child elements that had immediate child elements (and so on) of the same type? Like: <contract><contract><contract><contract> […]
- lmm 10y agoNo, there were a couple of layers in that case. But that doesn't actually help you add a child at the correct level, because the end of a contract would look something like: ... </contract> </subcontracts> </content> </contract> </subcontracts> </content> </contract>