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

151–160 of 179 posts

Re: The lost art of XML

#151

Post by riwsky »

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…

> What's missing is a widespread replacement for XSLT

jq says hello!

Re: The lost art of XML

#152

Post by fsckboy »

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…

to be fair

>XML shall be straightforwardly usable over the Internet.

is machine to machine communication

to me, XML is an example of worse is better, or rather, better is worse. it would never have come out of Bell Labs in the early 70s. Neither would JSON for that matter.

Re: The lost art of XML

#153

Post by aezart »

mkozlows wrote: post #22
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…

The part where it favorably mentioned namespaces also blew my mind. Namespaces were a constant pain point!

We use Mulesoft where I work, and XML namespaces are a constant issue. We never managed to define an API spec in such a way that the RAML compiler and the APIKit validator would both accept the same payload. In the end we just had to turn off validations in APIkit.

Re: The lost art of XML

#154

Post by fsckboy »

bytefish wrote: post #121

What I miss the most about the XML ecosystem is the tooling. And I think, this is what most people are sentimental about. There was a time it was so easy to generate contracts using XSDs and it made it easy to validate the data. OpenAPI slowly reaches parity to what I worked with in 2006. But what I do not miss is the over-engineering that happened in the ecosystem, especially with everything SOAP. Yes, when it worke…

>What I miss the most about the XML ecosystem is the tooling.

yes, me too! when using XML it rendered all the flexability and power of the unix tools pretty useless, and I missed them.

Re: The lost art of XML

#155

Post by somat »

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…

> OTOH namespaces, XSD, XSLT were great

I don't know, the few times I have had to XML, I went "This is not so bad, I don't know what all the fuss is about" until I hit namespaces. I don't know if I was just using an inferior library but namespaces sucked. The minute namespaces came into the picture all the joy left the project. And XSLT... I only ever did one thing with it "use the browser to turn demarc XML records into a webpage" and that was pretty cool. but it also firmly convinced me that XML is very much the wrong form factor for a programing language.

My personal thought is that css is not a sgml-like as a sort of rebellion against the way XML was taking over the world. It feels like author had written one too many XSLT's and said "Nope, it ends here, we are not doing that again." Because really, it is very weird that css does not use an XML syntax.

On the topic of the wrong form factor for a programing language. Another good contender is ansible when you try to use it's YAML looping constructs.

Re: The lost art of XML

#156

Post by ahf8Aithaex7Nai »

g-b-r wrote: post #147
ahf8Aithaex7Nai wrote: post #143

Earlier quoted context omitted.

> The complexity about XML comes from the many additional languages and tools built on top of it. It's not just that, is it? There are also attributes versus child elements, dealing with white space including the xml:space attribute, namespaces, schemas, integration of external document fragments with xinclude:include or &extern;. Each of these is a huge can of worms in its own right. There are probably more that I'm…

First, you're describing the parsing side, while the message I was replying to claimed that it can't be written by hand. Anyhow, schemas, XInclude and even namespaces are what I was referring to as additional languages of tools. In your application you use them if you want, they're not really part of XML. Of course even a parser for plain XML is a lot more complex than one for JSON, but people usually use libraries f…

I think I understand your point. I only brought parsing into play to illustrate that XML is complicated, not because it's my general focus. I wouldn't classify namespaces, etc. as additional languages and tools, but that's beside the point.

> in your application nothing prevents you from using a dumbed-down version of XML

That's right. And if XML were exactly that, then there wouldn't be so many people frustrated with it. Unfortunately, in a professional work context, you don't always have control over whether it stays within this manageable subset. Sometimes the less pleasant aspects simply come into play, and then you have to deal with the whole complicated mess.

Re: The lost art of XML

#157

Post by rcbdev »

com2kid wrote: post #125
badgersnake wrote: post #106

Earlier quoted context omitted.

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.

It is called DevUx and it is certainly a thing. If the tooling sucks and the entire ecosystem is hard to understand, people won't adopt a technology. XML was forced down everyone's throat for a decade! The second something else came along literally everyone who could jumped ship.

Interestingly, I've never heard the term 'DevUx' before. I suspect it's the same concept as Developer Experience, which I also find supremely important and historically underappreciated. Companies like JetBrains for example make a killing by being a company that really takes this aspect seriously.

On the other hand I've had a fellow developer laugh at me when trying to explain how this is important, so I'm unsure this is as important to others as it is to me.

Re: The lost art of XML

#158

Post by coffeebeqn »

Mikhail_Edoshin wrote: post #56

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.

This is an extremely cherry picked example. One liner with only attributes?

Re: The lost art of XML

#159

Post by bazoom42 »

The fundamental problem is XML was designed for textual markup formats but ended up getting used mostly for structured data. Many of the features like element/attribute distinction and mixed content is necessary for markup but unnecessary complexity for structured data.

JSON is perhaps an accident of history rather than deliberately designed, but for structured data interchange it is better because it is simpler.

Just like XML, JSON os getting used outside of its area. Using JSON for configuration files is absurd, since it doesn’t allow comments.

Re: The lost art of XML

#160

Post by hinkley »

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…

See, I was just gonna say, “what art?” but you put far more wood behind that arrowhead.

- XML-DSIG survivor.

Post reply on HN