Michael F. arrived to an ugly sight — an inbox full of messages with the same subject line. "ERROR: Invalid data near '<Carrier '" And that could only mean one thing. The shipping software company had released a patch to their web service. Having suffered through updates of ClearPath Logistics' software before, he knew exactly how this was going to go.

First, he typed up his usual message that boils down to (and I'm paraphrasing here) "WTF?" He had a contact, Dogan, that he usually alerted when their patches broke things.

Hours later, the second step. Michael received an email notifying him that yes, they did do an update, but no, the error was not their fault.

Minutes later, the third step. Michael responds to let them no that their software hasn't changed in a month, insiting that the problem is definitely on ClearPath's end.

The fourth step was the only step that varied from time to time. Sometimes a passive-aggressive apology from ClearPath, other times more accusations from the vendor that the problem was on their end. This time, Dogan did some analysis on the XML they'd received and replied quickly. Aha! The problem was on Michael's end!

Hi,

Some of these requests aren't well formed:
  <Carrier />
  <Service />
  <ReqDate />

These are not allowed in the API. Can we ensure the xml requests are well formed.
  <Carrier></Carrier>
  <Service></Service>
  <ReqDate></ReqDate>

Let me know if you have any questions.

What you may not realize is that ClearPath has their own version of XML. It's the same as regular XML, without support for those pesky empty element tags.