Live data from Hacker News

XML is a cheap DSL

unplannedobsolescence.com

91–100 of 274 posts

Re: XML is a cheap DSL

#91
post #10
post #7

XML is notoriously expensive to properly parse in many languages. Basically, the entire world centers around 3 open source implementations (libxml2, expat and Xerces), if you want to get anywhere close to actual compliance. Even with them, you might hit challenges (libxml2 was largely unmaintained recently, yet it is the basis for many bindings in other languages). The main property of SGML-derived languages is that…

FWIW, this is also one of the reasons MathML has never become the "input" language for mathematics, and the layout-focused (La)TeX remains the de-facto standard. Ergonomics of input are important because they increase chances of it being correct, and you can usually still keep it strict and semantic enough (eg. LaTeX is less layout-focused than Plain TeX)

MathML is used a lot in standards/publishing, such as with JATS and EPUB. MathML is also natively supported in the HTML specification.

Re: XML is a cheap DSL

#92

It kinda blows my mind that after XML we've managed to make a whole bunch of stuff that's significantly worse for any serious usage. JSON: No comments, no datatypes, no good system for validation. YAML: Arcane nonsense like sexagesimal number literals, footguns with anchors, Norway problem, non-string keys, accidental conversion to a number, CODE INJECTION! I don't know why, but XML's verbosity seems to cause such a…

"Any serious usage" starts at "it just works". JSON just works. Every language worth giving a damn about has a half-decent parser, and the syntax is simple enough that you can write valid JSON by hand. You wouldn't hit the edgy edge cases or the need to use things like schemas until down the line, by which point you're already rolling with JSON. XML doesn't "just work". There are like 4 decent libraries total, all ex…

> JSON just works.

Until it doesn't: underspecified numeric types and string types; parses poorly if there's a missing bracket; no built-in comments.

For many applications it's fine. I personally think it's a worse basis for a DSL, though.

Re: XML is a cheap DSL

#93
post #4

Given that that is had strong schema XSD verification built in, where you can tell in an instant whether or not the document is correct; it’s the right tool for a majority of jobs. My experience has been the people complaining about it were simply not using automated tools to handle it. It’s be like people complaining that “binaries/assembly are too hard to handle” and never using a disassembler.

what jobs require XSD verification?

E.g.:

> All consumers are required to meet schema validation. Schema validation is the verification that the operations inside the SOAP Body match the contract created by Jack Henry in the XSD documents. It should be noted, that the VER_x tags are required in the requests to meet schema.

https://jackhenry.dev/jxchange-soap/getting-started/developm...

Re: XML is a cheap DSL

#94
post #53

It kinda blows my mind that after XML we've managed to make a whole bunch of stuff that's significantly worse for any serious usage. JSON: No comments, no datatypes, no good system for validation. YAML: Arcane nonsense like sexagesimal number literals, footguns with anchors, Norway problem, non-string keys, accidental conversion to a number, CODE INJECTION! I don't know why, but XML's verbosity seems to cause such a…

> JSON: No comments, no datatypes, no good system for validation. I don't agree at all. With tools like Zod, it is much more pleasant to write schemas and validate the file than with XML. If you want comments, you can use JSON5 or YAML, that can be validated the same way.

I think you have it backward. Libraries like zod exist _because_ JSON is so ubiquitous. Someone could just as easily implement a zod for XML. I’m not a huge proponent of XML (hard to write, hard to parse), but what you describe are not technical limitations of the format.

Re: XML is a cheap DSL

#95
I like this post, but I gotta tell you, it just makes me want to dust off and write a bunch of s-expr tools to make that ecosystem equally or more attractive for DSLs.

If I do, the IRS will be the first to know about it! I'll staple an announcement to my 1040. ;-)

Re: XML is a cheap DSL

#96

Earlier quoted context omitted.

I keep seeing people make the same mistake as XML made over and over; without learning from it. I will clarify the problem thusly: > The more capabilities you add to a interchange format, the harder that format is to parse. There is a reason why JSON is so popular, it supports so little, that it is legitimately easy to import. Whereas XML supports attributes, namespaces, CDATA, DTDs, QNames, xml:base, xml:lang, XIncl…

I consider CSV to be a signal of an unserious organization. The kind of place that uses thousand line Excel files with VBA macros instead of just buying a real CRM already. The kind of place that thinks junior developers are cheaper than senior developers. The kind of place where the managers brow beat you into working overtime by arguing from a single personal perspective that "this is just how business is done, son…

Boy. Wait until you see how much of the world runs on Unix tabular columns

Re: XML is a cheap DSL

#97

Earlier quoted context omitted.

Much of XML’s complexity derives from either the desire to be round-trip compatible with any number of existing character and data encodings or the desire to be largely forward-compatible with SGML. A parser that only had to support a specified “profile” of XML (say, UTF-8 only, no user-defined entities or DTD support generally) could be much simpler and more efficient while still capturing 99% of the value of the la…

That's besides the point of this post. You're welcome to enforce such a profile on your documents, but the point of this post is the ease from throwing the whole ecosystem of out-of-the-box XML tools at it, tools which don't assume any such profile. (Now ITOT they may have implicit or explicit profiles of their own, e.g. where safe parsing, validation, and XSLT support are concerned, but they have a large overlap.)

Indeed, I was agreeing that the XML ecosystem as currently constituted has all the problems necovek pointed out.

But the W3C might have made some different choices in what to prioritize—notably, identifying a common “XML: The Good Parts” profile and providing the standards infrastructure for tools to support such a thing independent of more esoteric alternatives for more specialized use cases like round-tripping data from French mainframes.

Instead they chased a variety of coherent but insufficiently practical ideas (the Semantic Web), alongside design-by-committee monsters like XHTML, XSLT (I love this one, but it’s true), and beyond.

Re: XML is a cheap DSL

#98
post #80

The cheaper DSL is lisp. Cheap to parse, extend, transform. And you can have real macros and of course it's all executable. Oh and the universe is written in lisp (but mostly perl).

LISP, unfortunately, is only cheap within a pretty narrow bounds: when you've got a suitable environment already set up and running, and all your collaborators are happy to work with it.

Re: XML is a cheap DSL

#99

I like this post, but I gotta tell you, it just makes me want to dust off and write a bunch of s-expr tools to make that ecosystem equally or more attractive for DSLs. If I do, the IRS will be the first to know about it! I'll staple an announcement to my 1040. ;-)

This is exactly the same sentiment I had reading the article. Seems like a good weekend project to write a schema validating LSP server for S-expressions (with autocomplete).

Re: XML is a cheap DSL

#100
FWIW you can do a better job with the JSON structure than in the article:

    {"GreaterOf": [
        {"Value": [0, "Dollar"]},
        {"Subtract": [
            {"Dependency": ["/totalTentativeTax"]},
            {"Dependency": ["/totalNonRefundableCredits"]}
        ]}
    ]}
Basically, a node is an object with one entry, whose key is the type and whose value is an array. It's a rather S-expressiony approach. if you really don't like using arrays for all the contents, you could always use more normal values at the leaves:

    {"GreaterOf": [
        {"Value": {"value": 0, "kind": "Dollar"}},
        {"Subtract": {
            "minuend": {"Dependency": "/totalTentativeTax"},
            "subtrahend": {"Dependency": "/totalNonRefundableCredits"}
        }}
    ]}
It has the nice property that you're always guaranteed to see the type before any of the contents, even if object keys get reordered, so you can do streaming decoding without having to buffer arbitrary amounts of JSON. Probably not important when parsing a tax code, but can be useful for big datasets.
Post reply on HN