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

101–110 of 179 posts

Re: The lost art of XML

#101

Post by pkphilip »

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…

For most data that is structured in JSON now, you could have easily done the same in XML using a simple text editor.

I agree with the author that XML is very similar to S expressions but with the brackets replaced by closing tags.

Parsing XML wasn't complex either. There have been many good libraries for it in pretty much most languages

Re: The lost art of XML

#102

Post by froh »

mkozlows wrote: post #26
froh wrote: post #23

Earlier quoted context omitted.

that's underselling xml. xml is explicitly meant for data serialization and exchange, xsd reflects that, and it's the reason for jaxb Java xml binding tooling. get me right: Json is superior in many aspects, xml is utterly overengineered. but xml absolutely was _meant_ for data exchange, machine to machine.

No. That use case was grafted onto it later. You can look at the original 1998 XML 1.0 spec first edition to see what people were saying at the time: https://www.w3.org/TR/1998/REC-xml-19980210#sec-origin-goals Here's the bullet point from that verbatim: The design goals for XML are: XML shall be straightforwardly usable over the Internet. XML shall support a wide variety of applications. XML shall be compatible with…

please bear with me...

data exchange was baked into xml from the get go, the following predate the 1.0 release and come from people involved in writing the standard:

XML, Java, and the future of the Web Jon Bosak, *Sun Microsystems* Last revised *1997.03.10*

section on Database interchange: the universal hub

https://www.ibiblio.org/bosak/xml/why/xmlapps.htm

Guidelines for using XML for Electronic Data Interchange Version 0.04

*23rd December 1997*

https://xml.coverpages.org/xml-ediGuide971223.html

the origin of the latter, the edi/xml WG, was the successor of an edi/sgml WG which had started in the early 1990, and was born out of the desire to get a "universal electronic data exchange" that would work cross platform, vms, mainframes, unix and even DOS hehe, and to leverage the successful sgml doc book interoperability.

was it niche? yes. was it starting in sgml already? and baked into xml/xsd/xslt? I think so.

Re: The lost art of XML

#103

Post by jklowden »

pkphilip wrote: post #101
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…

For most data that is structured in JSON now, you could have easily done the same in XML using a simple text editor. I agree with the author that XML is very similar to S expressions but with the brackets replaced by closing tags. Parsing XML wasn't complex either. There have been many good libraries for it in pretty much most languages

If only there was one good library. libxml2 is the leading one, and it has been beleaguered by problems internal and external. It has had ABI instability and been besieged by CVE reports.

I agree it shouldn’t be hard. On the evidence, though, it is. I suspect the root problem is lack of tools. Lex and yacc tools for Unicode are relatively scarce. At least that’s what’s set me back from rolling my own.

Re: The lost art of XML

#104

Post by debugnik »

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…

> and it brought from it a bunch of things that are useless outside a markup language

It is a markup language. The mistake was trying to use it for anything else.

Re: The lost art of XML

#105

Post by wvenable »

benrutter wrote: post #57
wvenable wrote: post #47

Earlier quoted context omitted.

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.

> XML is still the implementation tool for Microsoft Office and Open Office docs.

It is and that is a good thing. I can't tell you the number of times that an application storing it's data in XML has made it possible for me to do things that would otherwise be impossible.

But nobody authors these documents in XML. It's just an application storage format. It could just as easily be Sqlite.

Re: The lost art of XML

#106

Post by badgersnake »

com2kid wrote: post #29

I remember spending hours just trying to properly define the XML schema I wanted to use. Then if there were any problems in my XML, trying to decipher horrible errors determining what I did wrong. The docs sucked and where "enterprise grade", the examples sucked (either too complicated or too simple), and the tooling sucked. I suspect it would be fine now days with LLMs to help, but back when it existed, XML was a hu…

There are a lot of good arguments against the XML ecosystem, but "I'm too lazy or dumb to understand it" is not one of them.

Re: The lost art of XML

#107

Post by badgersnake »

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…

I had great experiences with XSD as a contract in systems integration scenarios, particularly with big systems integrators. It's pretty clear whose fault it is when somebodys XML doesn't validate.

Re: The lost art of XML

#108

Post by cbondurant »

> the mapping is direct ... > or with attributes

so it isn't direct? That's what you're saying. You're saying that there's two options for how to map any property of structured data. That's bad, you know that right? There's no reason to have two completely separate, incompatible ways of encoding your data. That's a good way to get parsing bugs. That's just a way to give a huge attack surface for adversarially generated serialized documents.

Also, self documentation is useless. A piece of data only makes sense within the context of the system it originates from. To understand that system, I need the documentation for the system as a whole anyway. If you can give me any real life situation where I might be handed a json/xml/csv/etc file without also being told what GENERATED that file, I might be willing to concede the point. But I sure can't think of any. If I'm writing code that deserializes some data, its because I know the format or protocol I'm interested in deserializing already. You cant write code that just ~magically knows~ how its internal representation of data maps to some other arbitrary format, just because both have a concept of a "person" and a concept of a "name" for that person.

The problem with tags in XML isn't that they are verbose its that putting the tag name in the closing tag makes XML a context-sensitive grammar which are NIGHTMARES to parse in comparison to context-free grammars.

Comments are only helpful when I'm directly looking at the serialized document. and again, that's only gonna happen when I'm writing the code to parse it which will only happen when I also have access to the documentation for the thing that generated it.

"tooling that can verify correctness before runtime" what do you even mean. Are you talking like, compile time deserialization? What serialized data needs to be verified before runtime? Parsing Is Validation, we know this, we have known this for YEARS. Having a separate parsing and validation step is the way you get parsing differential bugs within your deserialization pipeline.

Re: The lost art of XML

#109

Post by Const-me »

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.

> It was never the right choice for API payloads and config files

Partially agree about API payloads; when I design my APIs I typically use binary formats.

However, IME XML is actually great for config files.

Comments are crucial for config files. Once the complexity of the config grows, a hierarchy of nested nodes becomes handy, two fixed levels of hierarchy found in old Windows ini files, and modern Linux config files, is less than ideal, too many sections. Attributes make documents easier to work with due to better use of horizontal screen space: auto-formatted JSON only has single key=value per line, XML with attributes have multiple which reduces vertical scrolling.

Re: The lost art of XML

#110

Post by bob1029 »

I would encourage anyone who thinks that XML is strictly inferior to attempt integration with certain banking vendors without use of their official XSD/WSDL sources. I've generated service references that are in the tens of megabytes. This stuff is not bloat. There are genuinely this many types and properties in some business systems. There is no way you could hand code this and still get everything else done.

The entire point of heavy-handed XML is to 1:1 the type system across the wire. Once I generate my service references, it is as if the service is on my local machine. The productivity gains around having strongly typed proxies of the remote services are impossible to overstate. I can wire up entirely new operations without looking at the documentation most of the time. Intellisense surfaces everything I need automatically as I drill into the type system.

JSON can work and provide much of the same, but XML has already proven to work in some of the nastiest environments. It's not the friendliest or most convenient technology, but it is an extremely effective technology. I am very confident that the vendors I work with will continue to use XML/WCF/SOAP into 2030.

Post reply on HN