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

The lost art of XML

marcosmagueta.com

Post reply on HN
Print view View original

51–60 of 179 posts

Re: The lost art of XML

#51

Post by masklinn »

cgio wrote: post #36

Not convincing. I was hoping it would go down the xslt path, which is a lost art. I despised and loved xslt at the same time, and there’s no question it was an artful enterprise using it.

XSLT I see as a tragedy. The match / patch processing model is so elegant, but the programming langage built around it is such a disaster (the XML, various langage semantics e.g. the implicit context, the gimped semantics, and the development environment or lack thereof).

I think a simplified Haskell-ish script host (à la Elm) with a smattering of debugging capabilities would have been amazing.

Re: The lost art of XML

#52

Post by locknitpicker »

_heimdall wrote: post #3

This is a debate I've had many times. XML, and REST, are extremely useful for certain types of use cases that you quite often run into online. The industry abandoned both in favor of JSON and RPC for speed and perceived DX improvements, and because for a period of time everyone was in fact building only against their own servers. There are plenty of examples over the last two decades of us having to reinvent solution…

Your comment doesn't sound well researched or thought all the way through. REST by definition is used nowhere at all, and virtually all RESTful APIs are RPC-over-HTTP that are loosely inspired in REST.

There is virtually zero scenarios where anyone at all ever said "This thing we're using JSON for would be easier if we just used XML".

JSON was the undisputed winner of a competition that never was in a great part because of the vast improvements over DX. I remind you that JSON is the necessary and sufficient subset of JavaScript that allowed to define data, and to parse it all anyone had to do was to pipe it to a very standard and ubiquitous eval(). No tooling, no third-party module, no framework. Nothing. There is no competition at all.

Re: The lost art of XML

#53

Post by matkoniecz »

acabal wrote: post #30

XML lost because 1) the existence of attributes means a document cannot be automatically mapped to a basic language data structure like an array of strings, and 2) namespaces are an unmitigated hell to work with. Even just declaring a default namespace and doing nothing else immediately makes your day 10x harder. These items make XML deeply tedious and annoying to ingest and manipulate. Plus, some major XML libraries…

> even if its feature set is strictly inferior

and often having less bizarre and overly complex features is a feature by itself

Re: The lost art of XML

#54

Post by bni »

Developers (even web developers!) were familiar with XML for many years before JSON was invented.

Also "worse is better". Many developer still prefer to use something that is similar to notepad.exe, instead of actual tools that understand the formats on a deeper level.

Re: The lost art of XML

#55

Post by Tiberium »

kenforthewin wrote: post #17

> This is insanity masquerading as pragmatism. > This is not engineering. This is fashion masquerading as technical judgment. The boring explanation is that AI wrote this. The more interesting theory is that folks are beginning to adopt the writing quirks of AI en masse.

At least I'm not the only one who noticed. It's genuinely weird and unsettling how such AI-written blog posts nowadays get to the top of HN easily.

Re: The lost art of XML

#56

Post by Mikhail_Edoshin »

Another thing I disagree with is the idea that JSON uses fewer characters. This is not true: JSON uses more characters. Example:

    
    {"bbbb":"bbbb","cccc":"cccc"}
See that the difference is only two characters? Yet XML also has a four-character element name, which JSON lacks. And JSON is packed to the limit, while XML is written naturally and is actually more readable than JSON.

Re: The lost art of XML

#57

Post by benrutter »

wvenable wrote: post #47
lighthouse1212 wrote: post #28

XML was designed for documents; JSON for data structures. The 'lost art' framing implies we forgot something valuable, but what actually happened is we stopped using a document format for data serialization. That's not forgetting - that's learning. XML is still the right choice for its original domain (markup, documents with mixed content). It was never the right choice for API payloads and config files.

I think XML for documents lost to markdown. Between markdown and HTML, there is no need for XML in that domain anymore either.

XML is still the implementation tool for Microsoft Office and Open Office docs. I wouldn't hold those up as the gold standard or anything, but it's hard to see how Markdown could capture everything that XML does for, say, powerpoint or excel.

Re: The lost art of XML

#58

Post by wombatpm »

nine_k wrote: post #40
in_a_society wrote: post #13

Smells like an article from someone that didn’t really USE the XML ecosystem. First, there is modeling ambiguity, too many ways to represent the same data structure. Which means you can’t parse into native structs but instead into a heavy DOM object and it sucks to interact with it. Then, schemas sound great, until you run into DTD, XSD, and RelaxNG. Relax only exists because XSD is pretty much incomprehensible. Then…

XML grew from SGML (like HTML did), and it brought from it a bunch of things that are useless outside a markup language. Attributes were a bad idea. Entities were a so-so idea, which became unapologetically terrible when URLs and file references were allowed. CDATA was an interesting idea but an error-prone one, and likely it just did not belong. OTOH namespaces, XSD, XSLT were great, modulo the noisy tags. XSLT was…

Don’t forget the whole DOM vs SAX processing mess. Big documents would routinely kill parsers by running out of Memory.

XSLT was cool. Too bad XSL and Apache-FOP never took off.

Re: The lost art of XML

#59

Post by locknitpicker »

zarzavat wrote: post #18
striking wrote: post #4

I tried using XML on a lark the other day and realized that XSDs are actually somewhat load bearing. It's difficult to map data in XML to objects in your favorite programming language without the schema being known beforehand as lists of a single element are hard to distinguish from just a property of the overall object. Maybe this is okay if you know your schema beforehand and are willing to write an XSD. My usecase…

You have to use the right tool for the job. XML is extensible markup, i.e. it's like HTML that can be applied to tasks outside of representing web pages. It's designed to be written by hand. It has comments! A good use for XML would be declaring a native UI: it's not HTML but it's like HTML. JSON is a plain text serialization format. It's designed to be generated and consumed by computers whilst being readable by hum…

> It's designed to be written by hand.

This assertion is comically out of touch with reality, particularly when trying to describe JSON as something that is merely "readable by humans". You could not do anything at all with XML without having to employ half a dozen frameworks and tools and modules.

Re: The lost art of XML

#60

Post by ivan_gammel »

locknitpicker wrote: post #52
_heimdall wrote: post #3

This is a debate I've had many times. XML, and REST, are extremely useful for certain types of use cases that you quite often run into online. The industry abandoned both in favor of JSON and RPC for speed and perceived DX improvements, and because for a period of time everyone was in fact building only against their own servers. There are plenty of examples over the last two decades of us having to reinvent solution…

Your comment doesn't sound well researched or thought all the way through. REST by definition is used nowhere at all, and virtually all RESTful APIs are RPC-over-HTTP that are loosely inspired in REST. There is virtually zero scenarios where anyone at all ever said "This thing we're using JSON for would be easier if we just used XML". JSON was the undisputed winner of a competition that never was in a great part beca…

>REST by definition is used nowhere at all

There exist plenty of people actually using REST. It can reduce complexity of SPAs.

Post reply on HN