While JSON's strength is its (relative) simplicity, XML's strength was always its power. Combined with an XML schema, you can create strongly typed documents with arbitrary data-types. For example, it's easy to define, oh, I don't know, a date time field in a way that isn't stringly typed.

Of course, that's what also creates its complexity. XML is big, and bloated, and expensive to parse. Which brings us back to the old days of SOAP- the Simple Object Access Protocol, essentially an XML remote procedure call. It was powerful, but complex, with lots of interlocking standards. With its Web Service Description Language (WSDL), the service could even be self documenting, laying out all the objects and fields you could interact with.

With all that web service tooling, it's trivial to expose core elements in your object model as web service end points, which is great if your object model is clean and easy to understand. It sorta sucks if you're the vendor Paul C ends up needing to work with.

This is an API exposed by a shipping service, and it's clear that "consistency" wasn't part of its original goal. So they have fields like <strAccountNumber> and <strAccountNo>. That gives you the hope that maybe at least they standardized on Hungarian notation, but don't worry, in other places it's just called AccountNumber. Similarly, there's <strUserName> and <strUsername>, which caused no end of confusion, especially as the WSDL wasn't always accurate.

But the sample Paul wanted us to look at was this one:

<WayBillInfo>
    <AccountNumber>23962</AccountNumber>
    <Waybill>SH0000317</Waybill>
    <Date>2022-11-09T00:00:00+02:00</Date>
    <Time>1900-01-01T09:06:05.11+02:00</Time>
    <Hub>JNB</Hub>
    <Code>73</Code>
    <Description>Added via Webservice</Description>
    <MovementDescription>Added via Webservice</MovementDescription>
</WayBillInfo>

Specifically, look at the <Date> and <Time> fields. The date field holds a date formatted as a string- with a time portion that is ignored. Similarly, the time field holds a time formatted as a string with a date part that's ignored.

"Why couldn't these be the same field?" you might ask. Or, "Why couldn't they use the schema to define a better date or time representation?" Because they didn't care is likely the correct answer to both those questions.

Paul sums it up: "There's lots of SOAP, but I don't feel very clean."

[Advertisement] ProGet’s got you covered with security and access controls on your NuGet feeds. Learn more.