David Storrs wrote on 2/2/19 11:57 PM:
Are there angles here that I haven't encountered or thought about yet?
As a fellow Racketeer with mixed feelings about XML, let me articulate for the list an angle you might've already considered...
One reason you might decide to use XML for a system interface (when not required to, nor encouraged by it possibly helping sales to some customers) is that you want to help the programmers on the other side of the interface to be correct, for very selfish reasons.
(We must remind ourselves not to underestimate the capacity for incorrectness in software systems development. We know it's bad, but it's worse than that.)
If everyone's messages have to validate to a particular DTD/schema, that lets you throw in what's effectively a bunch of checking they can do themselves, on their side, gives them blame-pointing error messages, and eliminates some of the phases of incorrectness on their end.
Incorrectness phases avoided is less work for you (consider if they're talking to a service you're selling them, and/or contacting you for support when their code is broken, or their floundering becomes an enterprise-scale diplomatic problem for you), and less of you waiting on them (for, e.g., integration, or a sale), and presumably makes them happier, as well.
There are numerous other ways in software you could accomplish the same goals-- *but* XML is a popular open standard, so a lot of mutual understanding and agreement is accomplished instantly.
It's possible to not love everything about XML, yet to see that it has technical merits, and to see very practical value in a popular open standard interface. The practical value includes that a standard at the interface lets you use tools you like more on your side of the interface. This standard gives you the flexibility to innovate with Racket+XML, rather than everyone in that sector forced for a decade to all use IckyLang 2000 (which, admittedly, has a surprisingly slick transparent distributed model, IckySmear).
When you're considering XML for a particular real-world case, it might be helpful to try to think through scenarios of using XML vs. other plausible open standards or semi-standards, like Protobuf, or some convention over JSON or CSV. Who all will be on the other end of the interface? How will they implement it? What's everything that happens when the interface spec gets a new version? How messy is that going to be? How long does this have to keep working (e.g., medical records that might need to be interpreted perfectly 100 years and 10 corporate acquisitions later)? Etc.
BTW, if you do go with XML, you might find RELAX NG Compact syntax to be pleasant. And/or you could make a schema DSL in Racket that generates both various Racket interface code and the XML schemas in standard format, and maybe a SQL schema mapping, too (maybe even have your Racket DSL also generate some Java code shim for a customer's other system's proprietary plugin interface, while you otherwise move the larger system to open standard interfaces).
-- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
