When I were a lad...

[BritishLad88]

What are they using XML for? Don't tell me they are hooked up to a service bus and they have SOAP flying around.

That reminds me of my last contract at a bank 10 years ago, from what I'd heard they'd never changed.

Nothing like a couple of thousand lines of XQuery to put hairs on your chest.

precisely that. the big investment banks will unlikely to move away from XML anytime soon and I think they can't so that's the problem.

for most of us who work or has worked in the financial services would no doubt know they standardised a lot of their messaging between different systems using xml like markup language.

[BlasterBates]

precisely that. the big investment banks will unlikely to move away from XML anytime soon and I think they can't so that's the problem.

for most of us who work or has worked in the financial services would no doubt know they standardised a lot of their messaging between different systems using xml like markup language.

There are actually advantages to XML and the slight improvement in performance is not worth the huge costs in ripping up and replacing interfaces with a new standard which will also be out of date by the time they've completed their update.

[eek]

There are actually advantages to XML and the slight improvement in performance is not worth the huge costs in ripping up and replacing interfaces with a new standard which will also be out of date by the time they've completed their update.

+1 - the fixed structure gives it a pile of benefits when compared to JSON

[PlanB]

+1 - the fixed structure gives it a pile of benefits when compared to JSON

There is nothing stopping you validating JSON, I do it all the time for my APIs. I think it's less an argument between XML and JSON than the accompanying technologies.

XML is pretty old school and generally comes with usage on service bus, wrapped in SOAP with a bit of WSDL and WSS chucked in for good measure.

That tech stack becomes pretty complicated and is often completely unnecessary. It's hard to test and does not scale well.

The whole microservice movement started in response to this.

[eek]

There is nothing stopping you validating JSON, I do it all the time for my APIs. I think it's less an argument between XML and JSON than the accompanying technologies.

XML is pretty old school and generally comes with usage on service bus, wrapped in SOAP with a bit of WSDL and WSS chucked in for good measure.

That tech stack becomes pretty complicated and is often completely unnecessary. It's hard to test and does not scale well.

The whole microservice movement started in response to this.

The entire reason why I need to use XML is to because I can use XSL to determine the structure of the document, in a way JSON just doesn't do.

And as I need to validate the integrity of the data via a digital signature the easiest way of doing that is to use a scheme which has a fixed (and strictly defined) structure rather than one that allows flexibility.

So perhaps next time instead of writing a post on look how clever you are, you might find that a better post would be to ask why are you doing it that way as the former type of post offers a lot of ways in which the original poster can show you up with the edge case they need to meet that you never thought about..

[jamesbrown]

Cap'n Proto or FlatBuffers is where it's at.

[eek]

Cap'n Proto or FlatBuffers is where it's at.

I'm not sure that helps me needing a single defined document structure for validation at rest..

[PlanB]

The entire reason why I need to use XML is to because I can use XSL to determine the structure of the document, in a way JSON just doesn't do.

And as I need to validate the integrity of the data via a digital signature the easiest way of doing that is to use a scheme which has a fixed (and strictly defined) structure rather than one that allows flexibility.

So perhaps next time instead of writing a post on look how clever you are, you might find that a better post would be to ask why are you doing it that way as the former type of post offers a lot of ways in which the original poster can show you up with the edge case they need to meet that you never thought about..

I don't want this to turn into a critique of your architecture or why only XML will do because from your explanation I still don't get it, I can only speak of my own experiences with XML and why most of the industry has moved on.

Yes JSON does not have strict structure, but there is always an implicit contract that is communicated between parties that integrate. I have hooked up many microservices with JSON and this has never been an issue, you don't blindly integrate with endpoints you have no clue about.

All these decisions are a trade off and the added complexity of the associated tech stack with XML is simply not worth the effort but I'm happy to be convinced only XML will do for your use case.

[BR14]

<yawn>
what's this spotty dev talk to do with the 'state of the market'?

[eek]

I don't want this to turn into a critique of your architecture or why only XML will do because from your explanation I still don't get it, I can only speak of my own experiences with XML and why most of the industry has moved on.

Yes JSON does not have strict structure, but there is always an implicit contract that is communicated between parties that integrate. I have hooked up many microservices with JSON and this has never been an issue, you don't blindly integrate with endpoints you have no clue about.

All these decisions are a trade off and the added complexity of the associated tech stack with XML is simply not worth the effort but I'm happy to be convinced only XML will do for your use case.

The first sentence in your original reply was "There is nothing stopping you validating JSON" to which I replied with an example where it wasn't the case.

But it's nice to know you work in a world where data integrity and piggy in the middle attacks aren't a risk. I'm old school enough that I protect for the latter even when data is moving internally within Azure and AWS..