this post was submitted on 24 Jan 2026
54 points (95.0% liked)
Programming
24651 readers
288 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
And that is issue why? The specification decided which one you use and what do you need. For some things you consider things as attributes and for some things they are child elements.
JSON doesn't even have attributes.
Alright, I haven't really looked into XML specifications so far. But I also have to say that needing a specification to consistently serialize and deserialize data isn't great either.
And yes, JSON not having attributes is what I'm saying is a good thing, at least for most data serialization use-cases, since programming languages do not typically have such attributes on their data type fields either.
I worded my answer a bit wrongly.
In XML
<person><name>Alice</name><age>30</age></person>is different from<person name="Alice" age="30" />and they will never (de)serialize to each other. The original example by the articles author with the person is somewhat misguided.They do contain the same bits of data, but represent different things and when designing your dtd / xsd you have to decide when to use attributes and when to use child elements.
Ah, well, as far as XML is concerned, yeah, these are very different things, but that's where the problem stems from. In your programming language, you don't have two variants. You just have
(person (name "Alice") (age 30)). But then, because XML makes a difference between metadata and data, you have to decide whether "name" and "age" are one or the other.And the point I wanted to make, which perhaps didn't come across as well, is that you have to write down that decision somewhere, so that when you deserialize in the future, you know whether to read these fields from attributes or from child nodes.
And that just makes your XML serialization code so much more complex than it is for JSON, generally speaking. As in, I can slap down JSON serialization in 2 lines of code and it generally does what I expect, in Rust in this case.
Granted, Rust kind of lends itself to being serialized as JSON, but well, I'm just not aware of languages that lend themselves to being serialized as XML. The language with the best XML support that I'm aware of, is Scala, where you can actually get XML literals into the language (these days with a library, but it used to be built-in until Scala 3, I believe): https://javadoc.io/doc/org.scala-lang.modules/scala-xml_2.13/latest/scala/xml/index.html
But even in Scala, you don't use a
case classfor XML, which is what you normally use for data records in the language, but rather you would take the values out of yourcase classand stick them into such an XML literal. Or I guess, you would use e.g. the Jackson XML serializer from Java. And yeah, the attribute vs. child node divide is the main reason why this intermediate step is necessary. Meanwhile, JSON has comparatively little logic built into the language/libraries and it's still a lot easier to write out: https://docs.scala-lang.org/toolkit/json-serialize.html