• Quite (unregistered)

    This doesn't exactly fill my hole with SOAP.

  • rosuav (unregistered)

    Even worse, the date and time both have timezones. Subtle problems incoming.

  • (nodebb) in reply to rosuav

    At least they are, in the example, both in the same timezone...

  • Foo AKA Fooo (unregistered)

    So much potential ...

    <Version>1.0</Version>
<numSubVersion>0.5</numSubVersion>
<FirstName>Paul D. Turner</FirstName>
<strMiddleName>Peter C. Meyer jr.</strMiddleName>
<stringLstNm>John T. Smith</stringLstNm>
  • Sauron (unregistered)

    @Remy Porter

    Although it'd definitely be a nice topic for a future article on TheDailyWTF, I think it is not such a good idea if the vendor define their own date or time representation.

    You know the drill. Y2K bug like stuffs. Leap years. Leap seconds. Calendar changes for test cases in 1582 between the Julian and Gregorian calendar (there's an old article on TheDailyWTF about a bugt because of that, so yes, it can happen). Etc.

  • (nodebb)

    I have an idea how this came. We had similar issues in our database object mapper. It could map database column to Java fields, but only in a 1:1 relationship. Now, their DB/2 instance had to TIMESTAMP type (or they just didn't use use), so they always used two columns: the DATE of the last change and the TIME of the last change (as an example). Now our mapper came into play and demanded two Java fields in the domain model. And since Java's Date type is in fact a timestamp (despite its name), there were two Date variables called lastUpdateDate and lastUpdateTime.

    Now this vendor might have used a similar persistence layer, and then they converted their data model to SOAP. That's why they're having two Date/Time fields, each of them only half filled.

    Addendum 2022-12-05 09:18: Correction: DB/2 had NO timestamp type

  • (author) in reply to Sauron

    While broadly speaking, I agree, I also am not a fan of stringly typed dates, even the respected ISO8601. I wouldn't complain about its usage, as a general rule, but if we're using something like XML, I'd much rather see the relevant parts called out as fields: <datetime tz="+2"><day>5</day><month>12</month><year>2022</year><minute>19</minute><hour>9</hour</datetime>

    It's not the most compact representation, but we're already using XML, compactness ran out the window.

  • (nodebb)

    I did my share of integrations with wonky SOAP implementations, and it's always depressing... I found one that needed the fields to be in a specific order (even though they were named). Otherwise, it just mixed up the values, and you either got an error, or undefined behavior.

  • Randal L. Schwartz (google)

    You had me from the title. :) SOAP is always WTF-worthy.

    But you haven't really lived until you've set up a system that talks XML over XML, or as an enhanced option, SOAP over XML. Yes, we had to write encoding routines to take business data into an underdocumented XML structure, then put that as an escaped encoded payload in a different XML structure for transmission. Mind you, the reply was similarly double-encoded, and could trigger errors at both levels.

    Fun times.

    Addendum 2022-12-05 12:11: I forgot. Both levels had sessions, with batches. So I had to manage lower-level session completing, and upper-level sessions completing on their own schedule.

  • CdrJameson (unregistered)

    <WayBillInfo> containing a <Waybill> made me physically wince.

  • Abigail (unregistered)

    Haven't used SOAP in a long time (15+ years), but the last time I had to deal with it was calling some Google API returning the multi-k XML document. Which contained syntax errors so it was unparsable. Not hard to fix but the SOAP library we used contained a bug and gave up parsing half way.

    In the end, I just took the raw buggy-XML document I got from the API and used a regex to extract the information I needed. Which was just a single integer.

  • (nodebb) in reply to Melissa U
    Correction: DB/2 had NO timestamp type

    Correction to your correction: DB/2 supports DATE, TIME and TIMESTAMP datatypes. DATE "stores a date value in the format MM-DD-YYYY or MM/DD/YYYY", TIME "stores a time value in the format HH:MM:SS or HH.MM.SS", and TIMESTAMP "combines the DATE and TIME types, but also stores down to the nanosecond in the format MM-DD-YYYY-HH.MM.SS.NNNNNN".

    I worked with mainframe DB/2 for a long time. I know that DATE, TIME and TIMESTAMP are well supported in DB/2.

  • WTFGuy (unregistered)

    Hoping I don't foul up the escaping ...

    @CdrJameson ref

    <WayBillInfo> containing a <Waybill> made me physically wince.

    Of course the <Waybill> element is actually a <WaybillID> or <WaybillNbr>. Just not named correctly. Which is to say that in context it's just about right.

  • (nodebb)

    I did a bit of SOAP+WSDL at one point with a PHP codebase (mine) and a .NET codebase (a colleague). If you followed the rules 100% - and I mean absolutely everything - then it worked really well. Take a shortcut anywhere and it was unreliable.

  • MaxiTB (unregistered)

    It's so funny that people these days make fun of SOAP and think it was bloated while other protocols hard hundreds and sometimes thousands of pages of specs for just one single contract and then there wasn't even an unified way to validate anything except for manual reviews :-)

  • (nodebb)

    Specifically, look at the <Date>

    Yeah, nothing wrong with that, an ISO formatted date/time...

    and <Time> fields.

    ...Wait! What?

  • سمارت بتس (unregistered)
    Comment held for moderation.
  • tbo (unregistered)

    Yeah, shipping sites in general are... not great.

Leave a comment on “Shipping a Gallon of Soap”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article