I used the OVAL "Open source Vulnerability Assessment Language", written in XML, daily to automate STIGs. Finding documentation for it was awful, but once I knew the syntax development was a breeze. Most chill job I ever had. A job like that is my retirement plan once I have enough money that salary no longer matters.
Don't Invent XML Languages (2006)
91–99 of 99 posts
Re: Don't Invent XML Languages (2006)
#92This is less about hating on XML and more about not reinventing the wheel. I quite like XML. Things like xpath make working with it, or getting data from it much easier than JSON; though I love jq syntax and can't wait until it starts being incorporated into languages. I don't even mind xslt provided it's not being over used.
Tim Bray [1] is a co-author of the original XML spec so he is probably not hating on XML so much, no. [1]: https://en.m.wikipedia.org/wiki/Tim_Bray
Yeah should have made it clear I was referring to a lot of the comments in this thread.
Re: Don't Invent XML Languages (2006)
#93Earlier quoted context omitted.
Generally there is misunderstanding of these markups. JSON came along because the JavaScript people found it convenient and more network-efficient (the irony being it's not really). But a million years later followed the schema-validation logic to back-fill deficiencies. In my opinion, one should go for XML when writing a portable document format of any variety to allow a vast array of schema validators, linters, and…
> Seriously, get rid of YAML, TOML, JSON. We already had INI, XML/XPATH/XSD I agree with you on YAML/JSON, but isn't TOML more or less INI with more data types and an actual specification?
Yeah sorry didn't mean to add TOML in there.
And to be fair, YAML is somewhat clean for what it is. I shouldn't have included that in my rant either. My main gripe is with the "JSON Everywhere" approach. :)
There's no one-size-fits-all solution to anything. If one is using JavaScript—great, use JSON as a way to transmit objects over the wire or unpack an object into a template. Just PLEASE do not use it for a configuration format. Visual Studio Code configuration is a nightmare of ugliness.
Re: Don't Invent XML Languages (2006)
#94Earlier quoted context omitted.
When I was writing an xbrl-to-json library I suddenly realized that they are not perfectly transferable. XML comes from spreadsheets, and so it was the first mover. Whereas json came from key-value pairs. I think key-value pairs are much easier to picture in your mind, and for the vast majority of work people are doing, it's just simpler. I think XML is wildly complicated for simply APIs.
My experience is a bit different. I use Chameleon+xmldict to generate dozen of different JSON formats, my input being a XML template plus Chameleon templating instructions. And I have found that JSON can be 100% percent expressed from XML.
JSON -> XBRL, but not all XBRL -> JSON
Re: Don't Invent XML Languages (2006)
#95Earlier quoted context omitted.
When I was writing an xbrl-to-json library I suddenly realized that they are not perfectly transferable. XML comes from spreadsheets, and so it was the first mover. Whereas json came from key-value pairs. I think key-value pairs are much easier to picture in your mind, and for the vast majority of work people are doing, it's just simpler. I think XML is wildly complicated for simply APIs.
XML comes from spreadsheets?
I'm sorry, I meant XBRL: https://en.wikipedia.org/wiki/XBRL
Re: Don't Invent XML Languages (2006)
#96I still see people, in 2024, writing new software and using XML as the data format. I don't have an example offhand, but I recently saw a hobby game engine using XML to store its engine-specific game object/scene data. Personally, I like to use TOML for anything that is likely to also be edited by humans and JSON or binary for something that will only ever be used by machines.
in the Java world? I've seen a couple XMLs on newer software but all from Java ecosystem, where there are substantial libraries in existence and the authors are already super familiar with it to the point where it's basically "free" Everything else is YAML, JSON, or TOML (especially in the rust world)
> in the Java world?
No. The most recent one I saw was a (hobbyist) C++ game engine that used XML to declare game entities and such.
Re: Don't Invent XML Languages (2006)
#97If you squint at XML, JSON, or YAML you see a kind of lispy data-structure shape, an n-arry tree. The reader has a context stack that they are pushing and popping from as they read. The real problem is that every problem space is isomorphic to one that has successively tighter context. And a format that is applicable to every problem is one that is applicable to no problem. I believe that computer languages must get…
No, xml is inherently different.
It’s a mark up language unlike the others which are data languages.
In xml you can nest data inside of data. In json you can have data structures that can hold data.
Eg., `lorem ipsum.` is not a thing in the others.
Re: Don't Invent XML Languages (2006)
#98If you squint at XML, JSON, or YAML you see a kind of lispy data-structure shape, an n-arry tree. The reader has a context stack that they are pushing and popping from as they read. The real problem is that every problem space is isomorphic to one that has successively tighter context. And a format that is applicable to every problem is one that is applicable to no problem. I believe that computer languages must get…
No, xml is inherently different. It’s a mark up language unlike the others which are data languages. In xml you can nest data inside of data. In json you can have data structures that can hold data. Eg., ` lorem ipsum . ` is not a thing in the others.
Your example shows taking a subset of a text node and wrapping in a tag. How many XML languages use this quality? The only ones I've ever worked with go to great lengths to not mix text nodes with other children nodes. And it's easy to see why such usage is considered poor practice: if you're making a language, you generally want more structure, not less.
I'm not familiar with the distinction between 'markup languages' and 'data languages'. Ignoring the text/structured mixing issue, which I think is vestigial in XML and unused in DSLs, these are all isomorphic to each other and can nest data inside of data in a similar way:
John Doe
30
New York
Software Engineer
ABC Tech
5
{
"person": {
"name": "John Doe",
"age": 30,
"city": "New York",
"employment": {
"position": "Software Engineer",
"company": "ABC Tech",
"years": 5
}
}
}
person:
name: John Doe
age: 30
city: New York
employment:
position: Software Engineer
company: ABC Tech
years: 5Re: Don't Invent XML Languages (2006)
#99Earlier quoted context omitted.
XML is a document markup language. As in, articles and books n stuff. How in hell is that comparable to anything "Lisp-syntax"?
Because lisp syntax (s expressions) are a cleaner and terser superset of all markup languages, and even of JSON-like representations. IOW, if you take Lisp expressions, add cosmetic syntactical changes like angle brackets and closing tags, then remove about 90% of functionality and cripple what's left, you'll have XML. Cripple it further and you'll have JSON.
> Because lisp syntax (s expressions) are a cleaner and terser superset of all markup languages
I don’t really follow this. What makes s-expressions a superset of markup languages?
What can’t you express in XML that you can with s-expressions?