XML to me always appeared too overheading. Example: Pure XML for a quad would be:
If you want to make this more compact, you could go for something like this:
But to be honest: this is no longer pure XML. It is custom strings embedded into XML.
You still need to parse the strings. If you accept that, then you also must accept this,
which takes the principle 1 step further:
And even 1 step further:
Then you finally land at the current LDRAW format, which simply encodes <quad>...</quad> by the leading "4":
I write this to argument against XML. I have to deal with it a lot elsewhere, and despite the fact that parsers
for it exist a lot etc. pp., its syntax overhead always is ineffective and annoying.
JSON would be something much better IMHO. Parsers for it exist as well a lot.
Code:
<quad>
<color>16</color>
<vertex><x>1</x><y>2</y><z>3</z></vertex>
<vertex><x>4</x><y>5</y><z>6</z></vertex>
<vertex><x>7</x><y>8</y><z>9</z></vertex>
<vertex><x>10</x><y>11</y><z>12</z></vertex>
</quad>
Code:
<quad>
<color>16</color>
<vertex>1 2 3</vertex>
<vertex>4 5 6</vertex>
<vertex>7 8 9</vertex>
<vertex>10 11 12</vertex>
</quad>
You still need to parse the strings. If you accept that, then you also must accept this,
which takes the principle 1 step further:
Code:
<quad>
<color>16</color>
<coordinates>
1 2 3
4 5 6
7 8 9
10 11 12
</coordinates>
</quad>
Code:
<quad>16 1 2 3 4 5 6 7 8 9 10 11 12</quad>
Code:
4 16 1 2 3 4 5 6 7 8 9 10 11 12
for it exist a lot etc. pp., its syntax overhead always is ineffective and annoying.
JSON would be something much better IMHO. Parsers for it exist as well a lot.