Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XML is a cheap DSL

unplannedobsolescence.com

Post reply on HN
Print view View original

181–190 of 274 posts

Re: XML is a cheap DSL

#181

Post by foltik »

phlakaton wrote: post #163
twic wrote: post #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,…

Aesthetically, I consider such JSON structures degenerate. It's akin to building a ECMAScript app where every class and structure is only allowed to have one member. If you want tagged data, why not just pick a representation that does that?

Because (imo) the goal should be to minimize overall complexity.

Pulling in XML and all of its additional complexity just to get a (debatably) cleaner way to express tagged unions doesn’t seem like a great tradeoff.

I also don’t buy the degenerate argument. XML is arguably worse here since you have to decide between attributes, child nodes, and text content for every piece of data.

Re: XML is a cheap DSL

#182

Post by Chaosvex »

conartist6 wrote: post #168
Chaosvex wrote: post #159

Earlier quoted context omitted.

I realised the other day that some of my test code has 'jumped' rather than 'jumps' for the intended panagram. Glad to see I'm not alone. :^)

Haha yeah someone pointed that out to me and I decided to leave it. I just needed a sentence, I'm not actually trying to show off every glyph in a font.

That was my reasoning for not fixing it, too. Fair!

Re: XML is a cheap DSL

#183

Post by catlifeonmars »

dale_glass wrote: post #39

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…

> Actually my own problem with XML was annoyance that back when I had the thought of doing a complex config format in XML, the idea of modifying it programmatically while retaining comments turned out to be absolutely non-trivial. In comparison with the mess one can make with YAML that's just a trivial thing

Only relatively few parsing libraries preserve the token stream metadata in the AST, most don’t even expose the AST. For the former, I can understand why, it’s a cross-cutting concern and adds complexity to the AST parse, but is almost always worth it.

Re: XML is a cheap DSL

#184

Post by 0xbadcafebee »

Someone1234 wrote: post #50
necovek wrote: 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…

The problem is that engineers of data formats have ignored the concept of layers. With network protocols, you make one layer (Ethernet), you add another layer (IP), then another (TCP), then another (HTTP). Each one fits inside the last, but is independent, and you can deal with them separately or together. Each one has a specialty and is used for certain things. The benefits are 1) you don't need "a kitchen sink", 2) you can replace layers as needed for your use-case, 3) you can ship them together or individually.

I don't think anyone designs formats this way, and I doubt any popular formats are designed for this. I'm not that familiar with enterprise/big-data formats so maybe one of them is?

For example: CSV is great, but obviously limited, and not specified all that well. A replacement table data format could be binary (it's 2026, let's stop "escaping quotes", and make room for binary data). Each row can have header metadata to define which columns are contained, so you can skip empty columns. Each cell can be any data format you want (specifically so you can layer!). The header at the beginning of the data format could (optionally) include an index of all the rows, or it could come at the end of the file. And this whole table data format could be wrapped by another format. Due to this design, you can embed it in other formats, you can choose how to define cells (pick a cell-data-format of your choosing to fit your data/type/etc, replace it later without replacing the whole table), you can view it out-of-order, you can stream it, and you can use an index.

Re: XML is a cheap DSL

#185

Post by 01HNNWZ0MV43FF »

PunchyHamster wrote: post #119
Someone1234 wrote: post #50

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…

Constant erosion of data formats into the shittiest DSLs in existence is annoying. "Oh, hey, instead of writing Python, how about you write in * YAML, with magical keywords that turn data into conditions/commands * template language for the YAML in places when that isn't enough * ....Python, because you need to eventually write stuff that ingests the above either way .... ansible is great isn't it?" ... and for some…

One issue with SQLite is that it's _not_ rewritten every time like JSON and XML, so if you forget to vacuum it or roundtrip it through SQL, you can easily leak deleted data in the binary file.

Re: XML is a cheap DSL

#186

Post by conartist6 »

phlakaton wrote: post #151
conartist6 wrote: post #60

Earlier quoted context omitted.

Just gonna drop this here : ) https://docs.bablr.org/guides/cstml CSTML is my attempt to fix all these issues with XML and revive the idea of HTML as a specific subset of a general data language. As you mention one of the major learnings from the success of JSON was to keep the syntax stupid-simple -- easy to parse, easy to handle. Namespaces were probably the feature to get the most rework. In theory it could also r…

I unfortunately disagree that your syntax is "stupid-simple." But it highlights an impedance mismatch between XML users and JSON users. JSON treats text as one of several equally-supported datatypes, and quotes all strings. Great if your data is heavily structured, and text is short and mixed with other types of data. Awful if your data is text. XML and other SGML apps put the text first and foremost. Anything that's…

Yeah "impedance mismatch" is a good way of putting it.

I wouldn't say we fall into the JSON camp at all though, but quite squarely into the XML-ish camp! We just wrap the inner text in quotes to make sure there's no confusion between the formatting of the text stored IN the document and the formatting of the document itself. HTML is hiding a lot of complexity here: https://blog.dwac.dev/posts/html-whitespace/. We're actually doing exactly what the author of that detailed investigation recommends.

You can see how it plays out when CSTML is used to store an HTML document https://github.com/bablr-lang/bablr-docs/blob/1af99211b2e31f.... Having the string wrappers makes it possible to precisely control spaces and newlines shown to the user while also having normal pretty-formatting. Compare this to a competing product SrcML which uses XML containers for parse trees and no wrapper strings. Take a look at the example document here: https://www.srcml.org/about.html. A simple example is three screens wide because they can't put in line breaks and indentation without changing the inner text!

Re: XML is a cheap DSL

#187

Post by phlakaton »

foltik wrote: post #181
phlakaton wrote: post #163

Earlier quoted context omitted.

Aesthetically, I consider such JSON structures degenerate. It's akin to building a ECMAScript app where every class and structure is only allowed to have one member. If you want tagged data, why not just pick a representation that does that?

Because (imo) the goal should be to minimize overall complexity. Pulling in XML and all of its additional complexity just to get a (debatably) cleaner way to express tagged unions doesn’t seem like a great tradeoff. I also don’t buy the degenerate argument. XML is arguably worse here since you have to decide between attributes, child nodes, and text content for every piece of data.

Depends on the application, I suppose. For OP's application, pulling in XML is no trouble and gives you a much better solution for typed unions.

To get better than XML, I think you're looking at something closer to a Haskell- or LISP-embedded DSL, with obvious trade-offs when it comes to developer ecosystems and interoperability.

Re: XML is a cheap DSL

#188

Post by hrmtst93837 »

petcat wrote: post #41
necovek wrote: 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.

[flagged]

Re: XML is a cheap DSL

#189

Post by Someone1234 »

PunchyHamster wrote: post #120
moron4hire wrote: post #77

Earlier quoted context omitted.

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…

Ah, such youthful ignorace. You just classified probably every single bank in existence as "unserious organization"

Yep, healthcare, grocery, logistics, data science. Heck it would be easier to list industries that DON'T have any CSV. There aren't many.

In terms of interchange formats these are quite popular/common: EDI (serialized as text or binary), CSV, XML, ASN.1, and JSON are extremely popular.

I 100% assure everyone reading that their personal information was transmitted as CSV at least once in the last week; but once is a very low estimate.

Re: XML is a cheap DSL

#190

Post by conartist6 »

phlakaton wrote: post #151
conartist6 wrote: post #60

Earlier quoted context omitted.

Just gonna drop this here : ) https://docs.bablr.org/guides/cstml CSTML is my attempt to fix all these issues with XML and revive the idea of HTML as a specific subset of a general data language. As you mention one of the major learnings from the success of JSON was to keep the syntax stupid-simple -- easy to parse, easy to handle. Namespaces were probably the feature to get the most rework. In theory it could also r…

I unfortunately disagree that your syntax is "stupid-simple." But it highlights an impedance mismatch between XML users and JSON users. JSON treats text as one of several equally-supported datatypes, and quotes all strings. Great if your data is heavily structured, and text is short and mixed with other types of data. Awful if your data is text. XML and other SGML apps put the text first and foremost. Anything that's…

As to the simplicity of the syntax I think you would understand what I mean if you were writing a parser.

It's particularly gratifying that you can easily interpret CSTML with a stream parser. XML cannot work this way because this particular case is ambiguous:
What does Name mean in this fragment of syntax? Is it the name of a namespace? Or the name of a node? We won't know until we look forward and see if the next character is :

That's why we write `` as `:Namespace: ` - it means there's no point in the left-to-right parse at which the meaning is ambiguous. And finally CSTML has no entity lookups so there's no need to download a DTD to parse it correctly.

Post reply on HN