Comment by generalk | Hacker News Reader

Comment by generalk | Hacker News Reader

Parent Full thread

On XML:

  > Not sure anyone really knows how XML happened. It’s 
  > basically the W3C’s fault, I think? It’s okay for some 
  > things but in the end I’m not sure it’s something anyone 
  > actually wants to use, it’s just going to be one more of 
  > those mistakes of the past.

Look, I was doing web dev when XMLRPC was in. For simple API stuff, JSON ended up being worlds better. No fiddly XML preamble, no schemas, no envelopes, just enough structure to be able to quickly pull out a couple of fields and we're set. Beautiful.

But let me tell you how much I appreciated XML and schema validation when we were working with fifteen different partners all using a standardized XML format with a schema. These are cats who were putting XSDs into their IDEs, clicking generate to get a class, and then just not caring.

So when our integrations broke because they were sending XML payloads that failed schema validation, our conversations were so easy.

Before you say "yes but technically you could have done the same with $OTHER_THING" -- sure it's possible, but XML is ubiquitous. Shit, our tools were in Ruby.

XML can be a bear, but sometimes you need a bear.

    XML can be a bear, but sometimes you need a bear.

Phrase heard at conferences in the 90's/2000's:

    "XML is like violence. If it doesn't work, you're not using enough of it."

> "XML is like violence. If it doesn't work, you're not using enough of it."

That same saying would also work replacing XML for soap (but not SOAP).

Made me laugh. :-)

Much agreement here, and from the exact same usecase. Probably the easiest B2B API integration scenario I worked with in the past was XML + XML Schema validation. And I still think XML is more readable in many cases than JSON, because while verbose the hierarchical structure is very easy to grasp, sometimes I misread an entire JSON document at first because I missed a quick "[" or "[{" (yes I have also misread XML documents because of the sheer weight of text you are presented with, so I'll call that one a wash).

I do agree with the XML criticisms around writability and complexity, though I think if you made a Venn diagram of the actual complexities inherent in managing a multi-client document-exchange system and the complexities of XML+Schema, you'd find that they're similar--and that many people who start building such an exchange with JSON documents end up stumbling into the same amount of complexity except in an ad hoc fashion.

It's funny, I wonder if other people have the same surreal experience: as the mass zeitgeist moved away from XML I was more or less like, okay, gotta go with it, as the driftwood goes with the currents. It's interesting how the zeitgeist functions. You can tell it's happening when people look at your functional system and are like, "Uhh, why aren't you using X...?" as though it's self-evident that you should drop everything and rewrite. Where X was, over the years (dating myself) {"Java", "PHP", "Node", "Rails", "Jquery", "REST", "Angular", "React", "Thrift", "NoSQL", "Protobuf", "Hadoop"}. Some of which I quite happily used, BTW, so the interesting part is the penetrative nature of the conversation, e.g. how the quite-functional-but-not-hot technology becomes the sick gazelle falling behind the herd, even as it is not empirically sick.

The problem I think is the extreme cargo-culting that exists with any popular technology -- half the arguments against the current flavor of the month really just begin with "no, this is not sent from god, and there do exist tradeoffs". Which is a fairly unreasonable starting point for a conversation between educated parties.

And then the ratchet turns, and the pendelum swings in reverse, and suddenly that thing sent from god was instead discovered to be sent from satan... and you're still trying to explain that tradeoffs exist

Yes. Can't agree more.

This coming from someone who hates XML, avoids it at nearly all costs - there are times it's the right tool for the job. And you list that time. If you have a 1-1 API contract, don't use XML. If you have 1-N, don't use XML. But if you have N-N API contracts? Where you're talking to half a dozen other services, and they're all talking to you? XML is an excellent choice.

It's a shame the original article didn't mention XPath which is a great feature when you're in the XML ecosystem. (Obviously JSON has jq, but that's not a standard - so there's no library version - and has some weirdness compared to XPath).

JSON has the equivalent JSON Pointer described in RFC 6901 (https://tools.ietf.org/html/rfc6901).

Basically, use the best tool for the job. If you're working with complex data structures from many sources, having data, validation and transformation languages (XML, XSD and XSLT) which have been co-developed and refined to basically be able to validate any third-party tool is invaluable. Sometimes extra safety is worth both the extra space and time.

> So when our integrations broke because they were sending XML payloads that failed schema validation, our conversations were so easy.

Fine, but with for example, Protobuf, you share a .proto file and so there's zero percentage chance of this happening.

No, with Protobuf, I send my counterparts a .proto file, and they 1) Don't know what the hell to do with it, not just because they don't know Protobuf but because 2) it wasn't included in the docs/dictionaries from the standards organization that set this all up in the first place.

XML files are little bit easier to debug

JSON schema achieves the same result and is fairly standard actually.

I was asked by a company to sort out complaints which were coming from recipients of their XML. The big win was doing validation against the schema on the outgoing XML!

One of my very, very, very first jobs (1999) was at a startup that was leaning very heavily into XML for dealing with structured data. A massive amount of time was spent dealing with issues related to hand-editing XML, so I went deep into building schemas, utilities to validate XML according to the schema, and finally building an editor that was capable of providing some XSD-enabled automagic.

Good times.

"Sometimes you eat the bear, and sometimes the bear eats you."

You only need to serialize faster than the guy next to you, or something

I hate xml so much. But I had a exam at my university a year ago where they would let me type a validation schema for a xml file in notepad++ and a checker on a computer with no internet. The fail rate for that exam was high and the course was outdated, api am glad they updated the curriculum now. I just hope to never work with xml data again.

Reply on news.ycombinator.com