Hacker News Reader

The reason is pretty clear, XML and its ecosystem was (is) enormously complex. When naively - but correctly - parsing introduces serious security vulnerabilities [1] you kinda have problems as a format. XML is just incredibly hard to get correct, understand, and be performant. JSON from the get-go was very easy to understand and start with so it gained the upper hand.

[1] https://owasp.org/www-community/vulnerabilities/XML_External...

I wouldn't consider that a parsing vulnerability - XML is relatively easy to parse - but rather an XML processing vulnerability, as in you must disable certain features (like arbitrary filesystem access) when processing an untrusted document.

With hindsight, an XML processing library should require that you turn features like that on, rather than require that you turn them off. Opt in to dangerous features rather than opt out of them in other words.

> for no clear purpose

performance may have been one driver, though for the "API web" which is the main use case there are better performing options than json

> everything looks like a waste of time overall

maybe all that matters in the end is to be gainfully employed. having multiple formats and standards helps with that. when the Euro got introduced in Europe thousands of FX traders busy trading national currencies had to switch to trading real estate.

>maybe all that matters in the end is to be gainfully employed. having multiple formats and standards helps with that. when the Euro got introduced in Europe thousands of FX traders busy trading national currencies had to switch to trading real estate.

Agreed.

XML was a bad fit for almost everything people did with it. The natural data model of XML is alien to all programming languages people use: it is alien to scripting languages because you want hashmaps and lists and it is alien to static languages because you want structs and lists. So you usually ended up having to have a two stage parser, with the first stage turning XML into some kind of DOM and then your handrolled DOM-to-internal-representation thing. That's also most of the justification for XML's ecosystem:

- You need XSD to make sure that your DOM-to-internal-representation code doesn't have to deal with garbage

- You need XPath to query XML directly if you don't want to convert it to something usable

- You need XSLT as a scripting language where the DOM isn't alien and awkward to manipulate

This is why there is no xslt equivalent (although you could argue that jq is that) and the various json schema solutions don't see much adoption, despite json being almost as old as XML at this point.

Honestly I don't agree with you, the abstract concept behind XML is just to provide a metalanguage for the representation of hierarchical data, and that's exactly what JSON and YAML do. They are completely interchangeable. XML is the general case for hierarchical data and provides tools for this general case. JSON got closer to the representation of list and hashmaps, but I see this as a mere convenience.

>This is why there is no xslt equivalent (although you could argue that jq is that) and the various json schema solutions don't see much adoption, despite json being almost as old as XML at this point.

I think it's incorrect to part from the assumption that nobody's gonna need a schema language, a query language, a mapping language or whatever. For the json schema this is blatantly untrue and you see many people creating their own version of a json schema because it's really needed. With XSLT you have a language for processing XML that's written in XML itself, what I find pretty nice. We're not gonna see a YAML processing language written in YAML any time soon though.

> the abstract concept behind XML is just to provide a metalanguage for the representation of hierarchical data

No it isn't, for the umpteenth time. It is a language for marking up text. Markup language deal with grammars - data serialization not data models, and if anything, having regular content models is a more characteristic property for markup languages compared to hierarchy.

> the abstract concept behind XML is just to provide a metalanguage for the representation of hierarchical data

What you are describing here is s-expressions, XML represents a far more specific type of data structure: a tree of nodes where each node is either a text node or a tag node. Text nodes are always terminal, tag nodes can either be terminal or not. Tag nodes also have a list of attributes, while text nodes do not. Each attribute is a key value pair where both the key and the value are text, but the key can only contain certain characters, whereas the value is unrestricted.

This is all fairly complicated and it doesn't really map well to almost anything.

Even the description is longwinded. You say:

> JSON got closer to the representation of list and hashmaps, but I see this as a mere convenience

I say that calling it "mere" convenience is underselling it. The data model of XML is of so little use that no programming langauge, besides XSLT, offers it as part of the language.

Vice versa hashmaps and list are nearly universal.

> I think it's incorrect to part from the assumption that nobody's gonna need a schema language, a query language, a mapping language or whatever

I didn't say that. I said that with XML the need for those tools is especially pressing because XML is such a poor fit for any programming language.

> you see many people creating their own version of a json schema because it's really needed

Sure, but you also see very low adoption for json schema, because it isn't needed as much as xml schema was.

So object graphs are rare in your opinion?

I fail to see why any typical use of XML _needs_ XSD, XPath, or XSLT. You certainly don't need XSD validation. It is trivial with stream processing to detect, skip over, and report on elements that shouldn't be there and every general purpose XML alternative has exactly the same issue, if not a worse one through use of eval style import of objects of questionable provenance.

Then you have no idea what your object structure now imported natively in your language contains, and you would have to post process it for vulnerabilities using introspection to find out.

In my view there just is no substitute for careful analysis of data submitted by any third party, and parsing an object into a tree structure and validating it after the fact is a questionable practice with untrusted data from anywhere. It may consume an arbitrary amount of resources before you have any idea whether the data in question bears even a passing resemblance to what it is supposed to be. If you have untrusted data you really shouldn't be using an unrestricted DOM constructing parser or eval style processing at all.

JSON is not a reinvention. It's two different things. XML is a markup language. It's for markup, so, do you need markup? Then don't use JSON. You don't need markup? Then don't use XML.

Markup is syntax that gives structure to text. Ironically there's a port of HTML to JSON syntax. Guess who did it.

> that's what an old professor told me

Well then your prof has no idea what (s)he's talking about I'm afraid. XML is just what the spec says on page 1 sentence 1 [1]:

> The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML.

Where "generic SGML" refers to the property of XML being always fully tagged and not needing markup declarations, but still able to make use of those for validation and limited forms of entity expansion. Full SGML OTOH uses markup declarations for tag inference/omission (as in HTML), attribute short form canonicalization (also as in HTML), Wiki syntaxes (as in markdown), stylesheets (as in CSS), and other features such as type safe/injection free templating, processing pipelines/document "views" and as general extension mechanism.

[1]: https://www.w3.org/TR/REC-xml/

Completely agree! But I think you meant "XSD" here:

> you can find the XSL to ensure the validity of an XML document

Thanks!

Because worse is better (which i mean in the unix sense of the phrase).

On the specific subject of schema, i think most of that is most users have no need or interest in a schema.

> most users have no need or interest in a schema

that is a strange statement. users must reach out for a schema practically as soon as some data is exchanged

the only users that don't need a schema are the ones operating within a controlled environment where everything has been somehow agreed or imposed (e.g. within a walled garden or when you control both sides of the exchange)

missing, incomplete, low-information schemas about what data is supposed to mean and how it can be used correctly etc is a major, major wast of time. in data science circles the joke is that 90% of the work is "data cleaning". what do you think data cleaning is about?

Even when you control both sides, code can still create unintended data due to bugs.

not to mention that future versions of yourself would think that past versions surely had mental bugs :-)

But should care about and actually care about are different things.

I think that the point there is that most users (and especially for RPC-ish applications, which is what most of the existing XSD documents are about) do not need a formal schema but the schema is only implied by the implementation. The issue there is that even if you have detailed formal schema and generate the interface code from that, there is still some ad-hoc contract between the generated interface code and rest of this application, and details of this ad-hoc contract will invariably leak through the interface code.

Designing formats for long term storage of some kind of data is another thing and there formal schemas make sense. But that is not something that most users (meaning developers) do frequently or often even ever.

>On the specific subject of schema, i think most of that is most users have no need or interest in a schema.

You have no idea, my friend. I came many times across the situation where people needed to have a JSON conformant with a schema and they just resorted to the ad-hoc badly written json-schema library du jour.

JSON is not a markup language, it is a serialization format.

A bad one at that. Not the worst (which would be yaml), but certainly not great.