And having been there in the 90s seeing XML and thinking "they've tried to do everything and got into a big mess" (XSLT anyone?) its so satisfying to see something simple and flawed displace it.
<note>
<paragraph>This is a <code vibe="positive">remarkable</code> text.
</paragraph>
</note>
{ "note":
{ "paragraph":
[ "This is a ",
{ "code": [ { "vibe": "positive" }, "remarkable" ] },
"text."
]
}
} {"note":
{"paragraph":
["This is a ", {"code": [{"vibe":"positive"}, "remarkable"]}, "text."]
}
}
["note",
["paragraph",
"This is a ", ["code", {"vibe": "positive"}, "remarkable"], " text."]]
This is also why I find Mithril.js so pleasant to use without JSX, because it's basically JsonML.
(note
(paragraph
"This is a " (code (:vibe . "positive") "remarkable") " text."))
With the benefit of a lot of hindsight, S-expressions seem like a superior choice for writing web applications (instead of HTML + JavaScript + some JS framework that writes HTML again (regardless of DOM vs Virtual DOM)).
Even though I prefer dialects like Fennel for programming rather than Common Lisp (I'd probably be fine with Clojure and Janet as well, but I haven't tried them), I wouldn't mind any dialect if that means I could use S-expressions instead of HTML+JS, assuming the amount of effort put into sandboxing that approach were as much as the effort that has been put into the current approach.
A "note" contains a "paragraph" object, which is an array of...? Strings, or objects where there are keys, but the values are arrays of...?
But, primarily, the thing that made JSON win out is that it reflects the existing semantic/data-structure model of an actual programming language (and approximates that of many others.)
XML (and XSchema, oh god), has this mixture of associative and sequentially ordered data, and two separate kinds of associative/nesting models (elements vs attributes). It wants to eat the world with its new semantic model, but it doesn't offer any particular semantic advantages and doesn't match what programming languages (or relational databases for that matter) work with.
And then on top of that the syntax is just ugly to read.
Still there was a moment in the 90s where I found XML kind of exciting and interesting. I don't really recall why now? Seemed everybody did.
XML is like the pager. It might seem clunky today, but it's better than having to tell the baby-sitter the phone number for the restaurant and theatre you'd be visiting that night.
There was DTD for that but probably rarely used.
XML also has a place as an interface, but it's much more niche, since most interfaces that are hierarchical-document-shaped are going to parse text instead of bracketed entities. I think we got a bit excited about how well HTML worked at the time.
For an object graph, CSV is less nice.
If I need a file or network message to represent a handful of object types with a bunch of relations that form a graph, I prefer XML (or JSON).
JSON is something I see as payload-only really. And YAML etc are human-craft only.
One thing I would change in XML is that closing a tag should not need to specify the name. <> should close any tag. It would make editing a bit easier and save a byte or two.
XML went for a syntax with fewer options because the complexity of SGML was considered a hinderance to its adoption.
- XML parsers were quite bad in the old days (2000), even in java land.
- Parser speed is a functin of the input size. And XML inputs are quite big, too big in my humble opinion.
- you have tag attribute and tag value, and so people get confused on how to use them for simple scenario.
- & must be escaped but no one does it. So when 'AT&T' ended up in a stream created by "hand" by a COBOL procedure, the XML got suddenly broken
- < and > musty be escaped, and so your SQL queries must be escaped
JSON is simply an associative hierarchical maps. A Lot of 1995 PHP code used the same data structure and just works. No attribute, only hierachy recursive structure.
Recusion always wins.
"path\to\file"
XML:
<a>path\to\file</a>
You don't have to parse the complete document to do something about it. You can use a streaming parser, and you can execute XSLT on the fly.
His reasoning was the problem isn't standard file formats. It's turning those into something a program can operate on as data[1]. And XML does not do that for you. No you have suck it in and then manually transform it into 'data'. So it just moves the problem from one place to another place. Which is a trash solution usually.
Far as I know JSON broken as it is does do that. At least with dynamic/ish languages.
[1] gross stuff people used to do like copy data structures in memory directly to a file actually solves that problem while being a maintenance nightmare.
JSON in scripting languages does "as well" as Java's java.io.ObjectInputStream/java.io.ObjectOutputStream and dontnet's System.Runtime.Serialization.XmlObjectSerializer.
aka: will explode in your face in spetacular fashion [causing security vulnerabilities or denial of service in the way] unless you take special care to only use explicit safe serializable objects, and you handle corner cases correctly (for example, Javascript `__proto__` naive deserialization).
The hard part is getting independent parties to agree on a common data exchange format. Processing the data in code is the easy part.
I used to love XSLT (I would probably still love it if I still used it, but the projects have mostly disappeared). Pattern matching is akin to event driven programming: just deal with what you have, if and when you have it. It was very clean and never broke.
The web sure didn't go that way...
XSLT 3 is a different beast, and XSLT 4 is being worked on at the moment.
There were some great resources - libraries of code fragments, similar in spirit to tailwind ui - and people did crazy things with them.
We eventually abandoned it, after many years. It was indeed terribly difficult to work out how a document got transformed, and when returning to a transform after a long time working in other languages, you could easily spend a day just trying to work out how some trivial thing worked.
I remember it fondly, but I wouldn’t do it again.
I do remember xsltproc being a game changer. it was still a CLI but it was really fast. So at least you could turn things around quickly. And IIRC Preview on the Mac would reload a PDF automatically if it changed. So you could get pretty close to a gui flow sometimes… as long as your document was short!
Until xsltproc, I’d been using whatever XSLT processor that came with Java, which (as always) was fine on a warmed up production server but sucked for REPL.
But what a gui could have helped with is working back from the output element to the node that generated it. That would have been sweet. But if memory serves anything commercial for XSLT back then was “enterprise licensing”, which we couldn’t afford.
I use this if I want to play around with XSLT.
Fun fact: Tim Bray was the/an editor on both specs:
* https://www.rfc-editor.org/rfc/rfc8259
I wonder if he'll commemorate/note the anniversary in some way:
For small messages though I agree JSON is smoother.
And is schema languages a complicated beast: Hell yes. Do we need it nevertheless: Yes
For example, I used to work at an ed-tech company that bought bubble test questions from Pearson, who provided their data in HUGE XML documents. If I remember correctly, they would do things like splitting the sentences of the test questions up so half the question was a tag attribute and the other half was an element. So, instead of just parsing questions, we'd have to parse them and then stitch them back together to make complete sentences. They did that with the answers too, I believe. So weird.
The JSON format makes it harder to abuse data like my example above and it is a lot easier to parse, so I'd reach for it before XML any day.
That would be a really good resource. I mean, anybody who has worked remotely with web technologies has an opinion about this topic but it would be interesting to compile an objective knowledge base and interpretation of why things evolved this way.
Nobody cares about 99% of that
Personally, I think you cannot operate a interface without a schema. There is always a contract. Within your own team you may not care but as soon as two team work with different order on things, contracts are needed.
And yes, SOAP, WS-*, XSLT, etc. is where the madness starts. But to be also honest, they used XML, they are not XML.