With JSON, the answer is always a name/value pair.
A schema language in which subordinate values being presented as attributes vs. elements was a presentational option in the concrete XML representation rather than a dictate of the schema language would solve this simply. There are already multiple schema languages for XML; needing a better schema language doesn't begin to provide a reason for a different representation language, since schema and representation language are separate concerns.
{
"employees": [
{
"name": "John Crichton",
"gender": "male"
},
{
"name": "Aeryn Sun",
"gender": "female"
}
]
}
<employees>
<employee>
<name>John Crichton</name>
<gender>male</gender>
</employee>
<employee>
<name>Aeryn Sun</name>
<gender>female</gender>
</employee>
</employees> employees:
- name: John Crichton
gender: male
- name: Aeryn Sun
gender: female <employees>
<employee name="John Crichton" gender="male" />
<employee name="Aeryn Sun" gender=female" />
</employees> <employees>
<employee>
<name>John Crichton</name>
<gender>male</gender>
<salaries>
<salary>10000</salary>
<salary>10000</salary>
<salary>10000</salary>
<salaries>
</employee>
<employee>
<name>Aeryn Sun</name>
<gender>female</gender>
</employee>
</employees>
JSON is not only less verbose, it is also more flexible and easier to read and understand. You don’t have to worry about should I use tags or attributes for that because I late might have to use sub tags, and that makes it far easier to use (and honestly parse as well because many XML documents I have gotten are very inconsistent).