I think it came down on the right side of reducing complexity rather than creating more but I was let go shortly after for the heinous crime of not being at my desk at 9am.
I think it came down on the right side of reducing complexity rather than creating more but I was let go shortly after for the heinous crime of not being at my desk at 9am.
Repeating myself, sorry:
I've done a lot of electronic medical records. At the time, SOAP, WSDL, HL7 3.x (XML format) reigned.
Techniques like yours is how our two person team was able to run circles around our much larger partners. In other words, while they were stuck trying to update and compile the XSDs, we just treated inbound data as screen scrapping.
Sharing a tip of my own: while xpath expressions are mostly great, we migrated to globbing expressions. The wildcarding allowed our scrappers to be a lot more flexible, robust in regards to all the chaotic mutant data we were receiving.
https://en.wikipedia.org/wiki/Glob_%28programming%29
PS- IMHO, The Correct Answer is to have path expression intrinsics, built right into the language. What LINQ should have been. Imagine if Java had regex intrinsics like Perl, instead of that weird library. Some idea.
If you need a globber, maybe you can extract it from this library. https://github.com/EsotericSoftware/wildcard It's nicer than mine, but I regarded mine as easier to debug.