Live data from Hacker News

How to Avoid Being Called a Bozo When Producing XML (2005)

hsivonen.fi

31–40 of 255 posts

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#31

XML is well regarded in the enterprise and languages like JAVA, C#, and VB.NET handle is spectacularly as an exchange format. I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there. I recall working with a partner who we were doing an identity federation with. Our system was using WS-Trust which is a SOAP/XML protocol. It wasn't ideal but everyone seemed to…

What do you think JAVA stands for? It's not an abbreviation. It's the name of an island and it's just 'Java'.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#32

XML is well regarded in the enterprise and languages like JAVA, C#, and VB.NET handle is spectacularly as an exchange format. I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there. I recall working with a partner who we were doing an identity federation with. Our system was using WS-Trust which is a SOAP/XML protocol. It wasn't ideal but everyone seemed to…

Well, XML is complicated, so it's hard to build support for, and it's verbose, so it's heavy on the wire. Frankly, I think JSON is a better format in most contexts.

The biggest problem with XML is that it's a node labeled tree that makes the schema choice between leaf node and attribute for scalar data almost arbitrary, whereas JSON is an edge labeled tree without the same choice. Most programming languages use edge labeled graphs for in memory data structures, so the semantic distance is lower with JSON.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#33

Why would anyone choose to use XML over JSON, other than for RSS?

Working in a statically typed language, and using schemas to ensure that the generated messages are correct, because we can generated classes that map onto the required data structures.

So far as I know JSON doesn't allow for that.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#34

XML is well regarded in the enterprise and languages like JAVA, C#, and VB.NET handle is spectacularly as an exchange format. I think it's bad reputation comes from anyone not using an enterprise language because the support just isn't there. I recall working with a partner who we were doing an identity federation with. Our system was using WS-Trust which is a SOAP/XML protocol. It wasn't ideal but everyone seemed to…

XML is very often the least bad format (compared with ASN.1, JSON, X12 EDI, CSV, and other interchange formats), particularly when dealing with statically typed languages. XML is a horrid chimera of SGML but at least it is both human readable, subject to machine validation, and gets the job done.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#35
post #32

Earlier quoted context omitted.

Well, XML is complicated, so it's hard to build support for, and it's verbose, so it's heavy on the wire. Frankly, I think JSON is a better format in most contexts.

The biggest problem with XML is that it's a node labeled tree that makes the schema choice between leaf node and attribute for scalar data almost arbitrary, whereas JSON is an edge labeled tree without the same choice. Most programming languages use edge labeled graphs for in memory data structures, so the semantic distance is lower with JSON.

Indeed. Furthermore, JSON readily differentiates between a single element {a: 'hello'} and a vector with one element {b: ['hello']}, as do most programming languages. XML does not, which leads to weird constructs like a to indicate that more than one name is possible. (Except .. if you actually use a schema with your XML parser, that indicates more than one is possible. But almost no one does). JSON also differentiates numbers from strings, etc.

As a result, in my experience, JSON tends to be more robust in real world use - even when a schema is available.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#36
post #32

Earlier quoted context omitted.

Well, XML is complicated, so it's hard to build support for, and it's verbose, so it's heavy on the wire. Frankly, I think JSON is a better format in most contexts.

The biggest problem with XML is that it's a node labeled tree that makes the schema choice between leaf node and attribute for scalar data almost arbitrary, whereas JSON is an edge labeled tree without the same choice. Most programming languages use edge labeled graphs for in memory data structures, so the semantic distance is lower with JSON.

Great explanation, I'd never heard it put that way before, thanks!

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#37

Why would anyone choose to use XML over JSON, other than for RSS?

If you are working with statically typed languages, the validation of XML is far superior to anything you can do over json, unless you want to write your own formats for defining data structures in JSON.

JSON, remember, was written for a language without even firm object structures. It is great in that environment but all exchange formats require external knowledge to validate, and XML unlike the others provides a way to do that.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#39

Why would anyone choose to use XML over JSON, other than for RSS?

For one, JSON didn't exist 15 years ago. For another, JSON didn't have validation or schemas 5 years ago.

Even there, the schemas and validation are very lightweight compared to what XML can do.

As I usually say, JSON is for relatively free-form, dynamically typed languages, but if one side is uses a statically typed language, XML is probably the better choice.

Post reply on HN