Live data from Hacker News

XML is a cheap DSL

unplannedobsolescence.com

41–50 of 274 posts

Re: XML is a cheap DSL

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

> XML Is a Cheap [...]

> XML is notoriously expensive to properly parse in many languages.

I'm glad this is the top comment. I have extensive experience in enterprise-y Java and XML and XML is anything but cheap. In fact, doing anything non-trivial with XML was regularly a memory and CPU bottleneck.

Re: XML is a cheap DSL

#42

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 extremely heavy, that have bindings in common languages, and the syntax is heavy and verbose. And by the time you could possibly get to "advanced features that make XML worth using", you've already bounced off the upfront cost of having to put up with XML.

Frontloading complexity ain't great for adoption - who would have thought.

Re: XML is a cheap DSL

#43
post #41
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…

> XML Is a Cheap [...] > XML is notoriously expensive to properly parse in many languages. I'm glad this is the top comment. I have extensive experience in enterprise-y Java and XML and XML is anything but cheap . In fact, doing anything non-trivial with XML was regularly a memory and CPU bottleneck.

Yup. SAP and their glorious idocs with german acronyms

Re: XML is a cheap DSL

#44
post #41
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…

> XML Is a Cheap [...] > XML is notoriously expensive to properly parse in many languages. I'm glad this is the top comment. I have extensive experience in enterprise-y Java and XML and XML is anything but cheap . In fact, doing anything non-trivial with XML was regularly a memory and CPU bottleneck.

That's if you parse the into a DOM and work on that. If you use SAX parsing, it makes it much better regarding the memory footprint.

But of course, working with SAX parsing is yet another, very different, bag of snakes.

I still hope that json parsing had the same support for stream processing as XML (I know that there are existing solutions for that, but it's much less common than in the XML world)

Re: XML is a cheap DSL

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

> can tell in an instant whether or not the document is correct

Speaking of "correctness"... It seems to me people almost never mention that while schema verification can detect a lot of issues, in the end it cannot replace actual content validation. There are often arbitrarily complicated constraints on data that requires custom code to validate.

This is analogous to the ridiculous claim that type checking compilers can tell you whether the program is correct or not.

Re: XML is a cheap DSL

#46
After thinking a bit about the problem, and assuming the project's language is javascript, I'd write the fact graph directly in javascript:

  const totalEstimatedTaxesPaid = writable("totalEstimatedTaxesPaid", {
    type: "dollar",
  });
  
  const totalPayments = fact(
    "totalPayments",
    sum([
      totalEstimatedTaxesPaid,
      totalTaxesPaidOnSocialSecurityIncome,
      totalRefundableCredits,
    ]),
  );
  
  const totalOwed = fact("totalOwed", diff(totalTax, totalPayments));

This way it's a lot terser, you have auto-completion and real-time type-checking.

The code that processes the graph will also be simpler as you don't have to parse the XML graph and turn it into something that can be executed.

And if you still need XML, you can generate it easily.

Re: XML is a cheap DSL

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

Author here. I agree with all this, and I think it's important to note that nothing precludes you from doing a declarative specification that looks like imperative math notation, but it's also somewhat besides the point. Yes, you could make your own custom language, but then you have created the problem that the article is about: You need to port your parser to every single different place you want to use it.

That's to say nothing of all the syntax decisions you have to make now. If you want to do infix math notation, you're going to be making a lot of choices about operator precedence. The article is using a lot of simple functions to explain the domain, but we also have switch statements—how are those going to expressed? Ditto functions that don't have a common math notation, like stepwise multiply. All of these can be solved, but they also make your parser much more complicated and create a situation where you are likely to only have one implementation of it.

If you try to solve that by standardizing on prefix notations and parenthesis, well, now you have s-expressions (an option also discussed in the post).

That's what "cheap" means in this context: There's a library in every environment that can immediately parse it and mature tooling to query the document. Adding new ideas to your XML DSL does not at all increase the complexity of your parsing. That's really helpful on a small team! I agonized over the word "cheap" in the title and considered using something more obviously positive like "cost-effective" but I still think "cheap" is the right one. You're making a cost-cutting choice with the syntax, and that has expressiveness tradeoffs like OP notes, but it's a decision that is absolutely correct in many domains, especially one where you want people to be able to widely (and cheaply) build on the thing you're specifying.

Re: XML is a cheap DSL

#49

Earlier quoted context omitted.

I read both, but I feel like they both miss what it was like to work with APIs back in the bad old XML days. Yes, XML is more descriptive. It's also much harder for programmers to work with. Every client or server speaking an XML-based protocol had to have their own encoder/decoder that could map XML strings into in-memory data structures (dicts, objects, arrays, etc) that made sense in that language. These were ofte…

Since you explicitly mentioned fashion, I assume you read this: > There is a distinction that the industry refuses to acknowledge: developer convenience and correctness are different concerns. They are not opposed, necessarily, but they are not the same thing. … The rationalization is remarkable. "JSON is simpler", they say, while maintaining thousands of lines of validation code. "JSON is more readable", they claim,…

My zod schemas are 100x simpler than all those SAX parsers I maintained back in the day. Honestly I kinda doubt you've worked with XML a lot. The XML data model is wildly different than that of pretty much every programming language's builtin data structure, and it's a lot of work to cross that bridge.

The article posted here makes a good point actually. XML is a DSL. So working with XML is a bit like working with a custom designed language (just one that's got particularly good tooling). That's where XML shines, but it's also where so much pain comes from. All that effort to design the language, and then to interpret the language, it's much more work than just deserializing and validating a chunk of JSON. So XML is great when you need a cheap DSL. But otherwise it isn't.

But the article you quoted makes the case that XML was good at more stuff than "lightweight DSL", that JSON was somehow a step back. And believe me, it really wasn't. Most APIs are just that.. APIs. Data interchange. JSON is great for this, and for all its warts, it's a vast, vast improvement over XML.

Re: XML is a cheap DSL

#50
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, XInclude, etc etc. They gave it everything, including the kitchen sink.

There was a thread here the other day about using Sqlite as an interchange format to REDUCE complexity. Look, I love Sqlite, as an application specific data-store. But much like XML it has a ton of capabilities, which is good for a data-store, but awful for an interchange format with multiple producers/consumers with their own ideas.

CSV may be under-specified, but it remains popular largely due to its simplicity to produce/consume. Unfortunately, we're seeing people slowly ruin JSON by adding e.g. commands to the format, with others than using those "comments" to hold data (e.g. type information), which must be parsed. Which is a bad version of an XML Attribute.

Post reply on HN