This isn't a WTF, it's the same as integrating with any enterprisey system using XML. Nothing ever works as expected and each side constantly blame each other. Eventually one side gives up and makes it "Just work".
A recent one was sample data and sample application producing tags like <data load=""> when the system actually expected <data_load>, but generated no error on invalid tags - it just silently ignored the data.<p>
Actually, this raises a point: why should it have a number_of_pieces element? That is just count(equipment_to_load/item_info)... And it might be sensible to wrap <item_info> nodes in an <items> element, just to get the advantage of more hierarchy, which is always better.<p>
I once worked for a medium-sized DoD contractor. The accounting lead quit right before we were bought by a much larger DoD contractor. The deputy general manager appointed the facilities guy to temporarily fill the position (who, believe it or not, was actually quite good at both roles). When the new accounting lead got a chance to get familiar with his job, he quickly realized why the previous guy had left. His department was a wreck. I don't think he had done anything illegal, but what he had done was done very poorly. So the new guy tries to tell his boss about all the problems they had, and the boss tells him (direct quote) "That can't be a problem because nobody's ever told me that before." Must be nice to live a world where new problems never crop up and all the old ones you never knew about simply go away.
My initial reaction to newly found bugs in code that I'd thought was well tested is often to think "You're the only one that's ever had a problem with this." Experience has taught me to keep my mouth shut and assume that the problem is real unless and until I've proven otherwise. I guess the WTF here is that the lead developer isn't very experienced.
Actually, this raises a point: why should it have a number_of_pieces element?
So that their hand-written XML parser can pre-allocate the array! Then watch it crash when you put in one too many item_info blocks!
Yep, that's most likely it! And therefore the way to get this fixed is to figure out how to DOS their parser with (ideally anonymous) XML payloads, repeatedly, until they get sick of their system crashing and perceive that maybe, just maybe, it might need a teeny tiny bit of fixitude.
more likely, 'it works fine when we send items one at a time, just send your items one at a time.'
I vote for this as the most likely cause. And the documentation is "correct" in that it accurately describes the system behaviour in the most common use-case.
It is "incorrect" in that it does not describe the bugged behaviour in other use-cases, but since Adam is the only person trying to operate in one of the not-most-common use-cases, the other team lead's statement is correct as far as it goes.
This all sounds like one of the many cases where the most gratifying method of resolution is the use of heavy weaponry. I recommend pulling a GAU-8 out of your back pocket and using it on the other team.
Out of 21 occurrences of "MQ", precisely one is not preceded by "WebSphere" (and it's the first Google hit for "ibm mq", so presumably it isn't some old page that wasn't updated for the alleged rebranding).
A recent one was sample data and sample application producing tags like <data load=""> when the system actually expected <data_load>, but generated no error on invalid tags - it just silently ignored the data. </data_load></data>
Lack of format validation if Very Enterprise Indeed, it seems. I have seriously never seen such poor (and frequently non-existant) input validation since I started having to interface with Java-EE technologies.