Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think "XML" is way too broad to meaningful discuss anything.

XML the data format is pretty great in its basic form. Not space-efficient, but unless you're dealing with bulk data, the inefficiencies don't matter unless you're googlescale or can't spare a millisecond. The format itself doesn't absolve you from the design work of your model; your ssn example is typical of the "CEO said we have to use XML now" rush-jobs at the peak of the SOA hypecycle.

XML data validation through XSD is a dream. The insistence of the JSON-people to sabotage any kind of data validation is absurd to me.

XML Webservices are easy and consuming them from a WSDL is easy.

SOA on an enterprise level was a stupid idea creating a giant expensive communication middleware with the ESB without delivering on the promises.

Every other thing in the XML space is brainfuck-level overcomplicated bullshit dreamt up by bored enterprise architects. WS-* is a cacophony of overcomplicated solutions to problems that only exist because enterprise architects dreamt of having a single data model that's inter-operable between companies.



> The insistence of the JSON-people to sabotage any kind of data validation is absurd to me.

I don't understand what you mean by this. JSON supports schemas which can be used to validate input. It's not super advanced, but it's functional.


JSON schema aren't part of the JSON definition, and JSON itself suffers from lacking good handling of types such as dates.

JSON itself succeeds as a way to represent JavaScript objects but it is far less useful than XML for representing custom types, which are easily enforced through XML Schema.

JSON Schema adds some of this, but it isn't a standard (yet).


XML schemas aren't part of the XML definition either, although, granted, they're an official recommendation too.


Having written a bunch of XML schemas and a bunch of JSON schemas at the same time while integrating multiple third party APIs, I can unreservedly say that JSON schema is awful.

It just about works, but it's horrible to write and horrible to maintain. What you can actually do with the validation is surprisingly limited in some forms and the fact that you have to write JSON to write the schema shows just how non-user-friendly JSON is.

A friend told me that she writes JSON schemas in YAML and then uses a build step to downgrade that to JSON for the actual validator. I wish I'd thought of that.


The JSON people were adamant about discouraging what https://json-schema.org/ ended up being. There's a reason JSON.org never linked to it (even back when they had a full screen of links at the bottom of their page: https://web.archive.org/web/20180727095653/http://www.json.o... )


> XML Webservices are easy and consuming them from a WSDL is easy.

Maybe in theory, but I've never had a WSDL that was actually complete. In the end, it generated stubs of types and clients for me and I still had to do a lot of nonsense. The concept of a WSDL would be nice but in practice I've seen _so_ many people do them poorly and create a bad experience.


> Maybe in theory, but I've never had a WSDL that was actually complete. In the end, it generated stubs of types and clients for me and I still had to do a lot of nonsense. The concept of a WSDL would be nice but in practice I've seen _so_ many people do them poorly and create a bad experience.

In a previous life, I shipped many, many, many APIs that used consumed and/or delivered XML data. We'd ship WSDLs if asked, but it was far easier for customers and from a support perspective for us to use the WSDL to generate API clients ourselves and then add some of the necessary supporting bits like authentication. We'd ship these to customers and it made life easier for everyone, despite the overhead.


> XML data validation through XSD is a dream.

That assumes that the XSD is accurate. I'm currently working with a vendor that has probably the worst XML-based API I've ever seen and the XSDs they provide often don't provide 100% coverage and have bad complex type declarations, etc.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: