4 ms·
What XML has to do with bank-specific messages that have to be parsed and processed? It’s just a markup format.
by mremes 2y ago
What XML has to do with bank-specific messages that have to be parsed and processed? It’s just a markup format.
- svapnil 2y agoBanks add their own features to the spec - imagine they want to add a new "Bank only" attribute that makes their XML schema differentiated and better in some way. ISO20022 / XML allows this to be possible without breaking anything. In the past payment formats used to be fixed width text files - impossible to change or improve functionality for
- cyanydeez 2y agoCustom schema means nothing against improper implementation
- bilekas 2y agoThis has me a little dumbfounded as either really profound or slightly misguided. How do you mean? As I am reading this you think a custom schema wont effect an implementation, but how do you expect to implement an external service (API for example) without the required defined schema. That's kind of the definition of a schema in this scenario. Extending the schema might be another thing. But implementation can't work without adhering to the defined schema of the provider? Right?
- deleted 2y ago[deleted]
- cyanydeez 2y agoFirst name is defined as a string. Great. What's the first name?https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
- cuu508 2y ago> impossible to change or improve functionality for You have to think inside the box! What if, say, instead of lastname "SMITH" we used "SMITH,FEE: 5.65"
- patates 2y agoI wish this example was exaggerated.
- actionfromafar 2y agoI saw an airport running with stuff like this, too. A mixture of brilliant and insane engineering in that place…
- dawidloubser 2y agoExcellent example clearly from a fellow soldier from the trenches! As somebody who has built several instances of both payments- and travel booking systems, I have seen things in systems that "adhere to published schemas" (often because the schemas were beastly, design-by-committee hellscapes of extensibility) that defy belief. While there is a strong argument to be made that strict type systems in programming langues like Haskell and Rust make it very difficult to play outside of the rules, this is unfortunately not the case in practice when it comes to APIs - both at present where you have a JSON Schema or Open API spec if you are lucky, and in the past (XML Schema, SOAP). I wish that the ability to express a tight, fit-for-purpose schema or API actually resulted in this commonly being done. But look at the average API of any number of card payment gateways, hotels, or airlines, and you enter into a world where each integration with a new provider is a significant engineering undertaking to map the semantics - and the errors, oh the weird and wonderful errors... to the semantics of your system. I am glad to work in the space-adjacent industry now, where things are ever so slightly better. (Note the lack of sarcastic emphasis - it really is only _slightly_ better!)
- iTokio 2y agoYes, my son is really named BOB,FEE: -999999999.99
- ldjb 2y agoIt's the extensible nature of XML that gives it an advantage. You can add custom elements and attributes whilst conforming to the base schema. Granted, XML isn't the only format where this is possible. You can sort of achieve it with JSON, though XML's namespace system helps deal with name collisions. Adding bank-specific messages wouldn't be possible (or would be difficult) with fixed-column formats, for example, unless they had been specifically designed to be extended.
- j16sdiz 2y agoIso200022 are tagged as well.