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

221–230 of 274 posts

Re: XML is a cheap DSL

#221

Post by kgwxd »

AnimalMuppet wrote: post #79
jaen wrote: post #15

Or... you could just use a programming language that looks good and has great support for embedded domain-specific languages (eDSL), like Haskell, OCaml or Scala. Or, y'know, use the language you have (JavaScript) properly, eg. add a `sum` abstraction instead of `.reduce((acc, val) => { return acc+val }, 0)`. In particular, the problem of "all the calculations are blocked for a single user input" is solved by eg. app…

Or Lisp. "Looks good" might be something not everyone agrees on for Lisp, but once you've seen S-expressions, XML looks terrible . Disgustingly verbose and heavyweight.

And once you seen edn, everything looks terrible. both data formats and language syntaxes.

Re: XML is a cheap DSL

#222

Post by y1n0 »

y1n0 wrote: post #207
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,…

What I don't like are all the freaking quotes. I look at json and just see noise. Like if you took a screenshot and did a 2d FFT, json would have tons of high frequency content relative to a lot of other formats. I'd sooner go with clojure's EDN.

So I generated a tool to take a screenshot of text and do a 2d FFT on it so I could take my own comment literally.

I was wrong. There is seemingly more high frequency content in the xml. See [1] -- the right side is the xml.

[1] https://orbitalchicken.com/fft_formats.jpg

Re: XML is a cheap DSL

#223

Post by y1n0 »

g947o wrote: post #217
y1n0 wrote: post #207

Earlier quoted context omitted.

What I don't like are all the freaking quotes. I look at json and just see noise. Like if you took a screenshot and did a 2d FFT, json would have tons of high frequency content relative to a lot of other formats. I'd sooner go with clojure's EDN.

Eh. I doubt if human developers spend much time reading any such json files. Using jq etc will go a long way for any routine work.

We do where I work and I hate it.

Re: XML is a cheap DSL

#224

Post by somat »

dunham wrote: post #179
blackcatsec wrote: post #123

Earlier quoted context omitted.

Could you imagine hitting a rest api and like 25% of the bytes are comments? lol

Worse than that - people will start tagging "this value is a Date" via comments, and you'll need to parse ad-hoc tags in the comments to decode the data. People already do tagging in-band, but at least it's in-band and you don't have to write a custom parser.

See also: postscript. The document structure extensions being comments always bothered me. I mean surely, surely in a turing complete language there is somewhere to fit document structure information. Adobe: nah, we will jam it in the comments.

https://dn790008.ca.archive.org/0/items/ps-doc-struc-conv-3/...

Re: XML is a cheap DSL

#225

Post by phlakaton »

da_chicken wrote: post #219
GuB-42 wrote: 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…

I've said it before, but I maintain that XML has only two real problems: 1. Attributes should not exist. They make the document suddenly have two dimensions instead of one, which significantly increases complexity. Anything that could be an attribute should actually be a child element. 2. There should be one close tag: ` ` which closes the last element, which burns a significant amount of space with useless syntax. O…

I disagree on several points here:

1. I think attributes absolutely should exist. They're great for describing metadata related to the tag: e.g. element ID, language, datatype, source annotation, namespacing. They add little in complexity.

2. The point of a close tag with a name is to make it unambiguous what it's trying to close off.

It sounds to me like what you want is not a better XML, but just s-exprs. Which is fine, but not quite solving the same problem.

3. As far as schema support, it seems to me that JSON Schema is well-established and perfectly cromulent – so much so that YAML authors are trying to use it to validate their stuff (the poor bastards) – and XML schema validation, while robust, is a complex and fragmented landscape around DTD, XSD, RELAX-NG, and Schematron. So although XML might have the edge, it's a more nuanced picture than XML proponents are claiming.

4. As far as tabular data, neither XML nor JSON were built for efficient tabular data representation, so it shouldn't be a surprise that they're clunky at this. Use the right tool for the job.

Re: XML is a cheap DSL

#226

Post by somat »

da_chicken wrote: post #219
GuB-42 wrote: 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…

I've said it before, but I maintain that XML has only two real problems: 1. Attributes should not exist. They make the document suddenly have two dimensions instead of one, which significantly increases complexity. Anything that could be an attribute should actually be a child element. 2. There should be one close tag: ` ` which closes the last element, which burns a significant amount of space with useless syntax. O…

Attributes exist due to it's origin as a markup language. XML is actually (big surprise) a pretty good markup language. Where the tags are sort of like function calls and the attributes are args. With little to no information to be gleaned out of the text. The big sin was to say "hey the tooling is getting pretty good for for these sgml like markup languages. Lets use it as a structured data interchange format. It's almost the same thing". Now all the data is in the text and the attributes are not just superfluous but actively harmful as there is a weird extra data axis that people will aggressively use.

Re: XML is a cheap DSL

#227

Post by da_chicken »

0xbadcafebee wrote: post #184
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…

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)…

Eh, this escaping problem was basically solved ages ago.

If we really wanted to make a UTF-8 data interchange format that needs minimal escaping, we already have ␜ (FS File Separator U+001C), ␝ (GS Group Separator U+001D), ␞ (RS Row Separator U+001E), ␟ (US Unit Separator U+001F). The problem is that they suck to type out so they suck for character based interchange. But we could add them to that emoji keyboard widget on modern OSs that usually gets bound to + .

But if we put those someplace people could easily type them, that resolved the problem.

But, binary data? Eh, that really should be transmitted as binary data and not as data encoded in a character format. Like not only not using Base64, but also not using a character representation of a byte stream like "0x89504E470D0A1A0A...". Instead you should send a byte stream as a separate file.

So we need a way to combine a bunch of files into a streaming, compressed format.

And the thing is, we already have that format. It's .tar.lz4!

Re: XML is a cheap DSL

#228

Post by Spivak »

quotemstr wrote: post #169
conartist6 wrote: post #117

Earlier quoted context omitted.

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…

No, it was obviously and flagrantly incorrect, as evidenced by the success of interchange formats that do allow for comments, including many real world systems that pragmatically allow comments even when JSON says they shouldn't. This is Stockholm Syndrome. But what can we expect from a spec that somehow deems comments bad but can't define what a number is?

As long as they stay comments there's no harm. As soon as they become struct tags and stripping comments affects the document's meaning you lose the plot.

Re: XML is a cheap DSL

#229

Post by troupo »

dunham wrote: post #179
blackcatsec wrote: post #123

Earlier quoted context omitted.

Could you imagine hitting a rest api and like 25% of the bytes are comments? lol

Worse than that - people will start tagging "this value is a Date" via comments, and you'll need to parse ad-hoc tags in the comments to decode the data. People already do tagging in-band, but at least it's in-band and you don't have to write a custom parser.

Reminds me how old versions of .net used to serialize dates as "\/Date(1198908717056)\/".

Re: XML is a cheap DSL

#230

Post by zzo38computer »

omoikane wrote: post #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.

They mention those things, but they do not mention ASN.1.
Post reply on HN