Hacker News Reader

Comment by Cthulhu_ | Hacker News Reader

Part of me wishes XML was still in vogue, it and related technologies solved a lot of problems that alternatives like JSON and YAML are still trying to solve.

I mean the last thing I heard from XML was EXI, a new way to transfer XML documents; instead of encoding it into an ASCII representation and gzipping it, it instead (iirc) turns an XML document into a binary representation or stream containing events similar to SAX as mentioned in this article. That could then be reshuffled and compressed for further efficiency. It was a way to improve transfer performance by a lot at the cost of human readability on the line, but, nobody should read XML documents on the line and they would probably use a client (that understands EXI) anyway.

View on HN

Never understood the typical all/nothing hivemind developer view around XML and JSON/YAML. It is and should always have been a case of horses for courses - XML absolutely has its uses (structured markup, mixed human readable/data islands, schema validation and multi-schema markup), yes it was bad to try to use it for everything and it is poor and long-winded for short repeated key/value item markup, but its equally bad today to treat it as passe and useless, it excels in several areas where YAML manifestly fails. Outside key/value markup of fairly shallow tree structures where schemas are singular, absent or in flux (in nosql style) or for machine consumption only, JSON/YAML is also the wrong tool to reach for.

It was an overcomplicated design-by-committee mess.

The only cases where XML tech has survived is where it got in early and inertia has kept it there and because it was "good enough".

I genuinely dont know of anybody building new technology on a foundation of XML. There's always something simpler, with a lower bug surface that will handle the job better - even in its originally intended domain of document markup.

I don't know, xml represents multiline values so much better than json/yaml. Then when it comes to escaping reserved characters, wrapping it in cdata is a lot cleaner than json/yaml escaping.

I am currently building something new that uses xml for a properties file. My use case requires sql inside a properties file (without the use of additional .sql files). Really wanted to use json/yaml because I felt like I was in the 90s, but xml was just a lot better for this case.

  This: |
    Always "seemed" a lot cleaner to me.

I dont see why it doesnt accomodate SQL just fine.

JSON was never intended primarily for user readability. It's for sending data over a wire. Its focus was on parsing simplicity, ease of serialization and deserialization and to be incidentally readable.

Only works well if your text is a leaf and has no other contained entities/structure.

As I said, horses for courses. FWIW I actually like YAML for certain limited use cases, just not where XML is better. And vice versa.

  entity:
    attr: whatever
    text: |-
      Try to make this *look good* in **YAML**.

^ I have quite a lot of YAML hanging around these days like this.

Markdown is surprisingly effective as an XML document markup replacement.

Consider the case of embedding (composition is better than inheritance) data defined by a second schema inside a first schema. To quote The Zen of Python, "Namespaces are one honking great idea -- let's do more of those!". But no other format does embedding in any reasonable way (it's all ad hoc extensions on top of your serialization format).

>Consider the case of embedding (composition is better than inheritance) data defined by a second schema inside a first schema.

What do you mean by this "data defined by a second schema inside a first schema"? And why is it a good idea?

You have a text document (eg, LibreOffice) which is XML, and want to embed a SVG in it (which is also XML).

XML has tools to deal with this situation, where it knows that what's found inside <picture></picture> can be evaluated according to the SVG spec.

You also have namespaces, to deal with that a <title> might be a thing both in a text document and a song, and you may need to use both inside the same document without conflicting.

> Consider the case of embedding (composition is better than inheritance) data defined by a second schema inside a first schema.

How, exactly, is JSON with JSON Schema inadequate for that?

There's always something simpler than xml and json, and yaml is anything but simple. They didn't try to reduce the bug surface, json tried to be parseable with eval, yaml tried to be succinct to the point of deliberate ambiguity.

The only thing I really liked about XML was schemas (XSD I think?).

The ability to design a schema that could be passed around to let people validate the data and structure of an XML file before sending it was really slick. The schema designer tools were easy to use.

I actually enjoyed using WSDL based web services specifically because of this. You could take the file, which was just a schema and generate all the code and data structures you needed to interface with the API from any language…and you got the ability to validate your data client side before even bothering to send it.

It definitely had some pain points, but overall these were the good points that I remember.

GraphQL is probably the closest next evolution.

JSON Schema is a thing

I've just started looking into switching our integrations from XML to JSON.

Tooling around JSON Schema seems to be a bit lacking though. Like, Swagger UI and editor doesn't fully support the latest JSON Schema version, especially w.r.t. choice-like oneOf elements.

And if any of you know of any good tools to visualize a large JSON schema, similar to XMLSpy, that's compatible with the latest JSON schema version then I'd love to hear about it.

> Part of me wishes XML was still in vogue, it and related technologies solved a lot of problems that alternatives like JSON and YAML are still trying to solve.

If you have a problem solved by XML and not other technologies, you can still use XML.

> you can still use XML

Make sure you have thick skin. Your peers will laugh at you. And your colleagues may veto your choice.

Until you ask them to propose a robust solution for document structural validation.

> EXI, a new way to transfer XML documents; instead of encoding it into an ASCII representation and gzipping it, it instead (iirc) turns an XML document into a binary representation or stream containing events similar to SAX as mentioned in this article. That could then be reshuffled and compressed for further efficiency

How would this compare to protobuf, in terms of efficiency?

I don't think anyone's tried benchmarking protobuf against EXI yet, but I've played around with a .NET implementation (Nagasena: http://openexi.sourceforge.net/) and it does outperform Gzip both for compression efficiency and decompression/runtime performance, so long as you use a schema-accelerated parser. It can infer a schema (turning it into a 'grammar' to use the EXI-specific term), but a properly constructed XML Schema will always be fastest/most efficient, especially in low memory systems.

What problem did XML solve that JSON is still trying to?

Mixed content: <https://news.ycombinator.com/item?id=21397111>

XML's implementation for this is surprisingly intuitive. But to be fair, who tries to use JSON for modelling something like this? You're better off just embedding the XML in a JSON string:

{"markup": "<div>The <a href=\"https://www.json.org/\">JSON format</a> was invented by <em>Douglas Crockford</em>.</div>"}

Most JSON is consumed in the browser, which also has an XML/HTML parser engine sitting alongside the JSON one.

AFAIK some matrix client wanted json markup for messages.

> to be fair, who tries to use JSON for modelling something like this?

There are people who hold the opinion that "Everything XML wanted to be, JSON did better." <https://news.ycombinator.com/item?id=28667089>

Comments. And before you mention JSON5, so you know anyone who uses it?

Come to the Java and .NET world, still used a lot.

Reply on news.ycombinator.com