Hacker News Reader

Comment by oaiey | Hacker News Reader

XSD is not as bad as everyone claims. JSON Schema vs. XSD complexity is IMHO pretty much the same. Working with both over years.

DTD however, let us not talk about that. Let us just forget it.

I think the drama in XML usage was basically that a simple RPC (or resource query) had at least a dozen namespaces, standards and very long element names. But that is not the fault of XML but of SOAP/WS-*. XML itself can be very beautiful and simple.

Oh, and horrible DOM Apis ;). When working in semi-modern .NET parsing XML/JSON is super easy. Doing the same in JavaScript (out-of-the-box) is a drama.

View on HN

Namespaces killed xml. Such a bad design. It may have worked out better with every schema required to explicitly flatten in whatever they need from sub-grammars.

I see this json schema thing also seems to use long intricate URLs that you can only copy-paste to identify things... at least in this day and age if one does ID with unwieldy blobs, it'd be good to at least use some hash to get the benefits of content addressing.

Maybe someone can chime in but parsing XML seems very much more difficult than parsing JSON.

Just the raw parsing is a solved problem from a user's perspective, the issue arises when you ask yourself "into what" you parse or rather what the semantics of the tree is.

It even might not matter whether you parse it programmatically or not in some cases. Typically when looking at a given XML (or other data structure text representations) you can pattern match the semantics of what you see, but that is not always true, because everyone uses it in a different way, relying almost completely on schema and documentation to convey semantics, which in turn makes the format strictly inferior to JSON, which also doesn't have rich semantics but is simpler.

Parsing XML is just grammar like JSON is ... that is not more or less difficult. JavaScript just has a built-in JSON Parser (which translate JSON into JavaScript object).

As a consequence, JSON in JavaScript is super easy. Using XML is medium-hard.

In .NET using XML or JSON is easy (not super easy).

In C++ using XML or JSON is medium-hard.

Do not know the state of the art for Go, Rust, Java, ...

As a consequence, JSON is - from a JavaScript developer perspective - the holy grail. From a .NET/Java/C++ developer perspective it is just another format.

In can't agree more.

In Java, there's the JAXB ”parser“ which translates an XML schema into (mostly) straightforward classes. Correct initial setup is the only hard part.

The key difference is that there are no options when you parse json. You just parse it and get some lists and maps back.

In XML you have to decide if you want DTD or schema enabled (which could provide default values, and could be a security risk) and where abs how you resolve the DTDs from etc. Do you resolve references? And many option options.

So JSON benefits not just from a simpler structure, but also from less optionality.

You do not pull schemas dynamically. Schemalocation beyond editors is a pure theory thing. It is not default, it cannot be fast. Any serious developer has the schemas as files in their code when checking the data for compliance.

Basically, in a static typed language you decide for schema checking or not - like for Json -, serializing in structures or access in an API - like for Json.

It is just that JavaScript maps json directly in their dynamic object, array and native types. For xml that is an mismatch. For static languages both are an mismatch.

> Parsing XML is just grammar like JSON is ... that is not more or less difficult.

My understanding is that that's not the case. XML parsers are Pull or SAX based and it's weird as fuck.

You can abstract that out, but parser complexity isn't something to sneeze out. For one thing, parsing XML is notoriously dangerous - tons of vulns both at a design and memory management level.

> I think the drama in XML usage ...

What about:

- verbosity

- complexity of writing a parser

- complexity of dumping data

- DTDs

- data model which doesn't map directly to a scalar/array/associative array

... and so many other XML features that are either useless or painful just for RPC.

Verbosity is not a thing. We read HTML all the time.

Parser writing and dumping of data is equally complex for both JSON and XML. The only difference is that in JavaScript JSON is so much simpler due to the dynamic nature of the language and the core library. Out-of-the-box XML parsing in JS is just stone-age. Compare that to .NET System.Xml.XDocument and Newtonsoft.Json, then you can see the simplicity how an API could look (in a static type system ;))

No one needs DTDs. No modern contract is every spec'ed in DTDs. XSDSchema has superseeded that 20 years ago. The only issue with it, is that some entry level tutorials are still mentioning it.

The data model mapping depends a lot on the target language. In JavaScript XML is not a match but JSON is. Working with JSON in C++ is equally stupid as working with XML is.

The only stupid feature in XML is namespaces. Without that, it is simple.

> Parser writing and dumping of data is equally complex for both JSON and XML.

Strongly disagree. Sure, you can make XML which is easy to parse, but parsing arbitrary XML is hard. Namespaces (and their short prefixes), and custom entities are something that fly in my face any time I use XML but simply do not exist in JSON.

Dumping is usually OK but again, I've seen XML libraries replace short namespace prefixes with full URLs when dumping, making simple documents unreadable.

It's easy in JS too, just use a DOMParser

That is not a JavaScript API, that’s a DOM only API, meaning it’s not reproduced in the language spec. This is important because it won’t work in Node, for example, without a 3rd party library or someone implementing it in Node core.

JSON however is supported in the language spec

And DOM API is an example of bad API design. Compare that to a modern XML API (like .NET System.Xml.XDocument) and you never want to see Dom again

Reply on news.ycombinator.com