3 ms·

You're right. It's so much sillier to do this: <fruit id="10" name="orange"/> Than this: {"fruit": {"id":10, "name":"orange"}} because the first one

You're right. It's so much sillier to do this: <fruit id="10" name="orange"/> Than this: {"fruit": {"id":10, "name":"orange"}} because the first one is called a "markup language" and the second one is called an "object notation". I'm not buying it.

slig 12y ago
It can be done like this too: <fruit> <id>10</id> <name>orange</name> </fruit> Which one is better? I find it hard to decide, and I believe most people do. And that's why we see it mixed, often in the same XML document.
- bananas 12y ago
  The one you use is better (correct).
  - spopejoy 12y ago
    Utterly disagree. Attributes can actually have validated contents, such as enumerated lists, etc, and are attractively terse. Over-reliance on elements are why Maven pom files are such a verbose disaster, and probably the main reason why web developers puke when trying to stream data. Restating element names make for illegible, bloated data. Attribute-heavy XML is attractively terse and benefits from validation (unlike JSON).
    - bananas 12y ago
      But you can't change an attribute to a composite type in the future easily. As for maven POMs, I use Netbeans "add dependency" and that's about it so it's a non issue for me.
mantrax5 12y ago
As the joke goes you can write COBOL in any language, and you're the proof. In JSON a more typical format would be: {"id":10,"name":"orange"} Now why you need an id and a name is another smell, but let's leave that in for the sake of the example. You don't need "node names" in JSON. Typically objects of type "fruit" will be hosted in an array whose type you're always aware of by the contract of your service. Sure you can have polymorphism and hint the type in those exceptional cases: {"type":"fruit","id":10,"name":"orange"} But at least you include that if you need it, it signifies intent, and it's not done just to appease a markup language bent out of shape as a serialization format. By the way, it's curious you chose to use attributes in your XML example. Attributes aren't typically used to serialize object fields. Can you guess why?
- smrtinsert 12y ago
  You seem to have only one use case which appears to be serialization, that isn't nearly the world of what xml covers. Yeah I guess if you don't want to use a database for your blog application json serialization is fine. A lot of us need much more from our data than that. We need validation, we need a machine readable description format, and we need apis to leverage all this that doesn't change every day. The json community is constantly reinventing the latter. Who cares if it saves a few bytes in transmission, I don't know anyone who grumbles "oh great, the xml is making my internet slow today."
wtbob 12y ago
Far better than either is: (fruit (id 10) (name orange)) At least IMHO.

slig 12y ago

It can be done like this too: <fruit> <id>10</id> <name>orange</name> </fruit> Which one is better? I find it hard to decide, and I believe most people do. And that's why we see it mixed, often in the same XML document.

bananas 12y ago
The one you use is better (correct).
- spopejoy 12y ago
  Utterly disagree. Attributes can actually have validated contents, such as enumerated lists, etc, and are attractively terse. Over-reliance on elements are why Maven pom files are such a verbose disaster, and probably the main reason why web developers puke when trying to stream data. Restating element names make for illegible, bloated data. Attribute-heavy XML is attractively terse and benefits from validation (unlike JSON).
  - bananas 12y ago
    But you can't change an attribute to a composite type in the future easily. As for maven POMs, I use Netbeans "add dependency" and that's about it so it's a non issue for me.

mantrax5 12y ago

As the joke goes you can write COBOL in any language, and you're the proof. In JSON a more typical format would be: {"id":10,"name":"orange"} Now why you need an id and a name is another smell, but let's leave that in for the sake of the example. You don't need "node names" in JSON. Typically objects of type "fruit" will be hosted in an array whose type you're always aware of by the contract of your service. Sure you can have polymorphism and hint the type in those exceptional cases: {"type":"fruit","id":10,"name":"orange"} But at least you include that if you need it, it signifies intent, and it's not done just to appease a markup language bent out of shape as a serialization format. By the way, it's curious you chose to use attributes in your XML example. Attributes aren't typically used to serialize object fields. Can you guess why?

smrtinsert 12y ago
You seem to have only one use case which appears to be serialization, that isn't nearly the world of what xml covers. Yeah I guess if you don't want to use a database for your blog application json serialization is fine. A lot of us need much more from our data than that. We need validation, we need a machine readable description format, and we need apis to leverage all this that doesn't change every day. The json community is constantly reinventing the latter. Who cares if it saves a few bytes in transmission, I don't know anyone who grumbles "oh great, the xml is making my internet slow today."

wtbob 12y ago

Far better than either is: (fruit (id 10) (name orange)) At least IMHO.