• (nodebb)

    Add it to the list of things that you should never write yourself: cryptography, date/time handling, XML parsing, and frist posts.

  • LZ79LRU (unregistered) in reply to Dragnslcr

    I fundamentally disagree.

    That is a list, or rather a subset of the list of things that I think every software engineer should write at least once each in his lifetime. For writing them is the best way to learn, through practical experience, the intricacies and pitfalls of the underlying subject matter.

    Now actually using that crap you write in production? HELL NO!

  • (nodebb)

    TRWTF of course is that they cannot change the output of the API because the client side can't be bothered to fix broken code.

  • Sauron (unregistered)

    Call me cynical, but at least they didn't use regular expressions ;-)

  • John Ramsden (unregistered) in reply to Dragnslcr

    Google let me down on "frist post", although I've probably coded one of them at some point, or tried. Can you enlighten me on what they are, or was it a typo for "first post".

  • (nodebb) in reply to John Ramsden

    You must be new here. Go back through the history and look at many of the first comment posts.

    I'm surprised Google doesn't know about it. Maybe because its auto-correct makes it hard to search for, or perhaps some engineer there follows this site and has deliberately coded something that ignores them.

  • Maia Everett (github)

    TRWTF is these extremely generic XML-based data formats that sacrifice the flexibility of tags and reinvent XML atop XML in a case of the inner-platform effect.

    Since I assume the application knows the structure of the data it intends to parse, it could be simplified to something like

    <methodResponse>
  <foo>abcde</foo>
  <bar>12345</bar>
</methodResponse>
  • (nodebb) in reply to Maia Everett

    It's actually likely inner-inner-platform.

    Sometimes APIs do this so they never have to update the API spec. Of course that entirely defeats the purpose since they do have to update the "how do you use this API" document and there is no tooling to support that.

    The worst possible case is that someone wrote a single API, and it looks in a database to see what methods and parameters exist, and then constructs some sort of dynamic statement to be passed off to another module. It's even possible that someone wrote a UI with a big textbox labelled "Method Body" and some user can type VBScript or some other nonsense in there - all for the sake of avoiding whatever process the company has in place.

  • (nodebb)

    I work with a system that returns exactly this XML format as well (although I have not heard yet of a new JSON replacement), and I can confirm that this an inner platform API. A typical request looks like this:

    <methodCall>
    <methodName>tables.fetch_rule</methodName>
    <params>
        <param>
            <value>
                <string>[table-name]</string>
            </value>
        </param>
        <param>
            <value>
                <string>[key-value]</string>
            </value>
        </param>
    </params>
</methodCall>

    There's also fetch_rules, and insert-, update-, and delete_rule. Tables and members get added frequently to implement new features.

    Still, this is no good reason to use proper xml.

    Addendum 2024-06-27 13:20: no good reason to not use proper xml

  • MRAB (unregistered) in reply to Barry Margolin

    A quick search found this: https://thedailywtf.com/articles/Security-Frist!

  • (nodebb) in reply to Maia Everett

    Since I assume the application knows the structure of the data it intends to parse, it could be simplified to something like

    Hilariously, what you posted is pretty much what SOAP does, and SOAP was derided as the worst thing that ever happened in the history of APIs. It wasn't until about 2015 that the JSON-over-REST community started widely using OpenAPI specs to get advantages similar to what SOAP's wsdl did in 1998. I still see a lot of projects using a REST client-side library but hand writing paths and hand building classes to be serialized. To this day, you'll still see discussions on the best way to serialize dates, usually hand-waived away with a statement like "Use ISO 8601", without saying that they only honor one tenth of the standard and if you don't do it exactly like they expect you to do it, there will be problems.

  • Duke of New York (unregistered)

    A manager needed to parse XML and was not sure how to do it. "I know," he said, "I'll use large language models." Now his department had many more problems, and he was in line for a promotion.

  • M (unregistered)

    So they had a bug in their code, and didn't have a test that detected it. Not really a WTF.

    They're using an XML-library (looks like https://www.codeproject.com/Articles/1847/C-Wrappers-for-the-Expat-XML-Parser). They're using a SAX-like API (maybe the responses can be really big and they don't want to parse the whole structure into memory at once).

    TRWTF is that they know what the bug is, and don't fix it.

  • Tim (unregistered)

    it's not too late to throw away all that XML parsing code. just load it into a DOM (or dynamically typed data structure if the language supports it) and pull out the bits you want.

  • (nodebb) in reply to Tim

    it's not too late to throw away all that XML parsing code. just load it into a DOM (or dynamically typed data structure if the language supports it) and pull out the bits you want.

    Bold of you to assume that they

    1. Have unit-tests in place, that make banning the broken XML Parser implementation from all call sites in the code base anything less than a product-breaking-risk change and
    2. There isn't a lot of code that depends on the inaccurate behavior.

Leave a comment on “A Stack of XML”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article