• (cs) in reply to Severity One
    Severity One:
    It never ceases to amaze me that (a) vendors come up with such crap and (b) customers accept it.

    When you deal with a large vendor, you never to get to negotiate anything. So, if the alternative to this was to get 1000 sheets of paper to data entry, then you take this format and be happy with it.

  • Gary (unregistered) in reply to what
    what:
    Gary:
    PS:
    Already way ahead of you. (Scroll down to the last two examples)

    What if I want to put CDATA inside my XML payload? That's why I need to URLencode it.

    What if I want to put a url in my URLencoded payload? That is why I need to Base64 ecode it.

    What if I want to put Base64 blob in my Base64 encoded blob? Phew, I think we're finally safe.

    Really this is an inevitable drug interaction of two XML panaceas: XML as a messaging interface (well in this case, two messaging interfaces since there is a SOAP layer as well), and XML as a data structure - like taking snake oil for both your lumbago and your psoriasis.

  • (cs) in reply to Mr. S.

    I support the death penalty for people who engineer this kind of stuff.

    Mr. S.:
    We do this too. It does make SOAP a little easier...<snip>

    If SOAP is so unwieldy, then why are you using it?

  • Joshua (unregistered)

    Did something similar once. The automated layers delt with all the mess so the developer didn't have to unless they didn't have a copy of baseinputpacket or basereturnpacket classes, which means they shouldn't be calling it in the first place.

    What it looked like to me was xml in string variables, which is a little more sane. A simpler collection type would have been more suitable.

  • (cs) in reply to Brad Davis
    Brad Davis:
    Yeah, this isn't a WTF. One of the most common reasons for doing something like this is so you can extract the XML, create a standalone DOM from it and validate it against a schema. This is much harder to do if the piece you want to validate is actually just a node in a SOAP envelope. The point is that the encoded XML document is logically distinct from the soap envelope and even the response wrapper, so there's no good reason to make it all one big XML document.

    Now I remember why I stopped reading TDWTF comments: because TDWTF doesn't provide free blood pressure medicine to compensate.

    <Puts gun in mouth>
  • (cs) in reply to savar
    savar:
    Mr. S.:
    We do this too. It does make SOAP a little easier...<snip>

    If SOAP is so unwieldy, then why are you using it?

    QFT

    You made my day.

  • Ctc (unregistered) in reply to Brad Davis

    Yes and no -- yes, payload/data separate is sometimes ok to do with xml-in-xml (albeit with significant performance loss) -- but that wasn't done here. Rather it was a big-ass complete inclusion with a bogus root element (not SOAP). So there is very low chance of this making any sense whatsoever -- the only potential reason would be to work-around problems in a container that tried to parse it.

  • (cs)

    As usualy people are either oversimplifying, ignoring or merging issues. SOAP/XML can be used for both the "envelope" and the "contents". If the delivery is to be independent of the message, then contents SHOULD be encoded so as not to be processed as part of the envelope. If the delivery is to be "transparant" then everything should be in clear XML.

    XML should always be validated against a strict XSD. If you opt for "transparant" then ANY change impacts EVERY layer. Sometimes (rarely) is this appropriate.

    From my perspective (as a systems developer) the most fustrating thing is when data is logically multiple layers but is presented as a flat (albiet hierarchical) item.

    This requires ADDITIONAL work to separate the layers so that each can be validated within the prioper domain, and do do this in a manner that is robust against malformed or malicious messages.

  • Sanity (unregistered) in reply to Anonymous

    I really hope this guy is joking/trolling...

    Anonymous:
    I don't think this is a WTF. it seems that the result string would not always be XML, so it makes sense this way.

    If it wouldn't always be XML, what possible benefit could there be to wrapping it in SOAP? Seems the obvious solution would be to make it a RESTful service and use existing mechanisms to choose what the content is, like a Content-Type header.

    Then again, I tend to see SOAP as one giant WTF in the first place.

    Better yet, if it wouldn't always be XML, why not return a <string> tag when it's non-XML, and just return the XML when it is XML? Or does SOAP make that difficult?

    Anonymous:
    not to mention safety concerns, if the string is not sanitized for XML, what's to stop a bug from returning </result> and ruining the XML syntax?

    If that's really an argument, what's to stop a bug from returning an unescaped </result> anyway and ruining the SOAP syntax, and why is it more desirable for a bug to ruin the encapsulated XML than the enclosing SOAP?

    Or how about we stop manually emitting XML by concatenating strings together. It's the output version of trying to parse XML with regexes. Don't we have libraries to do this?

  • Gary (unregistered) in reply to Sanity
    Sanity:

    Or how about we stop manually emitting XML by concatenating strings together. It's the output version of trying to parse XML with regexes. Don't we have libraries to do this?

    In honor of a sidebar thread:

    document.write("<scr"+"ipt type='javascript'>"); document.write("document.write('We sure do!')"); document.write("</script>");

  • (cs) in reply to fake me
    fake me:
    Kempeth:
    They should really escape those ampersands...

    There is no escape from the Ampersand of Doom

    One of the biggest hazards of enterprise-y developmestruction: getting stuck and drowning in the amperquicksand!
  • (cs) in reply to DaveK
    DaveK:
    fake me:
    Kempeth:
    They should really escape those ampersands...

    There is no escape from the Ampersand of Doom

    One of the biggest hazards of enterprise-y developmestruction: getting stuck and drowning in the amperquicksand!
    It's either that, or get suffocated and absorbed by the rather large blob.
  • iToad (unregistered)

    So if this is xml, encoded in xml, is it actually xxml?

  • (cs) in reply to Brad Davis
    Brad Davis:
    Yeah, this isn't a WTF. One of the most common reasons for doing something like this is so you can extract the XML, create a standalone DOM from it and validate it against a schema. This is much harder to do if the piece you want to validate is actually just a node in a SOAP envelope. The point is that the encoded XML document is logically distinct from the soap envelope and even the response wrapper, so there's no good reason to make it all one big XML document.

    Except that now you not only have to schema validate it, you also have to parse it.

    Had you done it the way it was intended, the SOAP toolkit would have gotten it into a DOM that is more representative of the data (i.e. the objects generated by the toolkit). You can then make your logic layers perform the validation so that you can accept data from any source and pass it into the business logic/controller as a concrete type.

    Setting it up for a DOM means you may have to pass the DOM instance around to your logic and traverse the tree/XPATH the values you're looking for. Totally inefficient, plus everyone has to remember what XML Schema is in the DOM. You'll try to keep track of which schema is appropriate to pass into a given logic method using comments. Say goodbye to overloaded methods and good OO practices in general; you can't overload methods when all the parameters are the type of the DOM object.

    If you're not doing that, then you're parsing the DOM three times - once to get it into the DOM, once to schema validate it, and once to parse it back out of the DOM into your data objects. Lame.

  • Manadar (unregistered) in reply to Henrik

    Initech is also the name of the company from the movie Office Space. It could just be a placeholder name. :) The fact that someone actually named their company Initech is beyond me (Company from 2002, movie from 1999).

  • Gunslinger (unregistered)

    I'm just glad that I'm not working with web services.

  • ADINSX (unregistered)

    yo dawg we heard you like XML, so we put XML in your XML so you can agnostically transfer data while u agnostically transfer data

  • rfoxmich (unregistered)

    The real WTF - the vendor is respected.

  • (cs)

    I like how it is inside a <string> element. Sweet!

    I'm dealing with a company that does almost the exact same thing. Its not that big of a deal, except that I log the SOAP envelope. And when I want to just VIEW the xml, I've got to decode it first. I suppose I could have logged the decoded results, but...

    What gets me is a different company is returning all of its values in CDatas. Well actually not all of them, just some of them sometimes. Do they not know what CData is for?

  • Mechaniculus (unregistered) in reply to iToad

    This is what we have in a respectable vendor platform. xml embedded inside xml embedded inside xml...

    I guess we should call it XXXml?

    <diffgr:diffgram xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1"> <ReportConfiguration xmlns="http://tempuri.org/ReportConfiguration.xsd"> <ReportView diffgr:id="ReportView1" msdata:rowOrder="0" diffgr:hasChanges="inserted"> <ReportName>Search Orders</ReportName> <ViewName>TerminalDemurrageData</ViewName> <Type>LayoutView</Type> <Data><?xml version="1.0" encoding="utf-16"?> <ReportLayoutView xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <LayoutStyle>&amp;Full Layout Style</LayoutStyle> <ViewName>SearchOrdersReportView</ViewName> <UserName>View</UserName> <LayoutData>&lt;?xml version="1.0" encoding="utf-16"?&gt; &lt;ArrayOfKeyValuePair xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" /&gt;</LayoutData> <AutoSizeColumn>false</AutoSizeColumn> . . . . .

  • Mingol (unregistered)

    What's XML, and how is it useful?

  • (cs) in reply to rfoxmich
    rfoxmich:
    The real WTF - the vendor is respected.
    Of course they are. After all, they said so.
  • Soho (unregistered) in reply to iToad
    iToad:
    So if this is xml, encoded in xml, is it actually xxml?

    With this any level of compability can be achieved:

    x^nml, where n is the level of compability needed.

    Captcha: Populus, an awesome game.

  • e (unregistered) in reply to Mr. S.

    Then WHY are you using SOAP???

  • (cs)

    A real-world SOAP service (no I won't tell whose) returns (as declared in the WSDL) a single "string" value which is a XML document (with a custom schema that is available so you can parse it with JAXB) that contains a bunch of CDATA sections. Guess what's the contents of these CDATA sections - yes, yet other XML files (with different schemas for each CDATA section, "because they were designed by different teams"). So you have to build a lot of JAXB stubs and do some tweaking to get at the "real" XML documents...

    Honestly, what are XML namespaces for...?

  • anon (unregistered)

    smells like Axis...

  • (cs)

    Most of the web services offers by my vendors work this way. Our credit card processor is only a little bit better. It has one web method named "SoapOp" and this method has every possible parameter for any operation, as well as a parameter named "operation" to tell it what to do.

    UPS does the whole "XML blob in, XML blob out" thing, but at least they have a straight HTTP version of the service where this makes sense.

    On the other side, our networking team is making me consider encapsulating the entire request and response of our of our services in a generic message. As soon as they found out we were doing SOAP with a vendor, they routed us through a special proxy. The proxy does SOAP validation and now we have to get another team involved for any change to the SOAP interface. The other team is very slow and expensive, so we are very tempted to simply embed our data one more layer deep.

  • (cs)

    Let me see if I'm doing this right:

    Yo dawg, I heard you like XML so I put some XML in yo' XML so you can parse XML to parse some more XML.

    EDIT: Curses i was beaten to it!

  • (cs)

    If you can believe it, I've actually had to deal with worse. I had to deal with a wsdl that SAID string but returned xml, a complete and normal xml document inside of a soap response. This would choke the soap engine. When I first saw the wsdl, I was like, "Uh, is this escaped or wrapped in cdata?" "Escaped," they say. Come to find out they know not what they speak. I didn't approve of their string of xml, as most of you agree after seeing this, but I was willing to deal with it. When I found out they weren't even returning a valid response I put a stop on that implementation. I shouldn't have to go and write a garbage soap implementation just because your people are incompetent.

  • Nick (unregistered)

    and, regardless, several customers already use it tihs way.

    As if they have a choice...

    Reminds me when in a local pub I asked what beer they offer and they said "What do you mean what beer? We have Beer. If you want any fancy foreign beer - well nobody orders them and we don't have them". So how the **** can I offer anything you don't have???

  • Cryptomonicon (unregistered)

    We need the decryption key for WTF -- XML

  • Waffle (unregistered)

    I've XML'd your XML, pray I don't XML it further!

  • Allan (unregistered)

    Well Microsoft do this too...

    http://msdn.microsoft.com/en-us/library/bb277362%28v=office.12%29.aspx

  • Daniel O'Connor (unregistered) in reply to Jonathan
    Jonathan:
    Mr. S.:
    We do this too. It does make SOAP a little easier - no schema changes for every little response change, but I'd expect more from a third party, external-facing service.

    Not to say that doing this isn't a WTF.

    You have no schema changes because you don't really have a schema.

    Good, if we're talking XSD!

    What properly robust, web scale system freaks out it gets extra data?

    It's a huge pain to get someone to make a trivial change to a schema; which you need to render (elsewhere) but provides no value to the other party.

    They won't change and you have to fork your rendering code.

  • joe (unregistered)

    Meh, we've got something better on the project I'm working on: a web service sending XML... in binary.

  • Kempeth (unregistered) in reply to Jeff
    Jeff:
    Kempeth:
    Does that changevision thing in the ad come with the girl in the tshirt?
    No
    Excellent! I really don't need the tshirt...
  • Xzibit (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Yo dawg, I heard you like XML so I put some XML in yo' XML so you can parse XML to parse some more XML.
    [image]
  • hinek (unregistered)

    OMG! I had the same thing with a german authority. They have a custom software for their user management and every additional software they want to use, has to implement a interface to communicate with the user management.

    For this they wanted me (and every software they use) to implement a webservice they can push their user/right changes to. It has two methods one without argument to ping the webservice and one with one argument: a string.

    The string they pass to the webservice contains the xml. When I asked why they do this: 1. more flexible to later changes 2. more compatible to non-.NET webservices (what!!!)

  • jbee (unregistered) in reply to Coyne
    Coyne:
    Frankly, I think they need even more compatibility: 
         &lt;CompanyGetConnector&gt;
    Don't we all agree that is more compatible?

    I am not kidding. We use a SOAP-Service that does exactly this. twice escaped... why not triple ? no idea. maybe because of web 2.0 ? I see them change it to

         &amp;lt;CompanyGetConnector&amp;gt;

    in the age of web 3.0 :)

  • next_ghost (unregistered) in reply to Bryan the K
    Bryan the K:
    I'm disappointed, I was hoping for another day of hidden comments or at the very least unicorns.

    Does it say "by Remy Porter" below the title? No, it doesn't. And AFAIK nobody else does unicorns and hidden comments here.

  • (cs) in reply to Stretch
    Stretch:
    Sterling Commerce does the same thing. Useless piece of crap.

    Our product hits sterling and we don't send this crap, just a normal xml message. Not to say they are good at even receiving those messages considering the WSDL says a field can have 0 instances but they told me if I don't send an empty instance of the field their side blows up, but the messages are clear enough.

  • meh (unregistered)

    TRWTF is that XML isn't eXtensible at all, and that XML namespaces (which are supposed to enable nesting different schemas) never seem to work properly.

  • (cs)

    Now you have 2^^2 problems.

  • Design Pattern (unregistered) in reply to meh
    meh:
    TRWTF is that XML isn't eXtensible at all, and that XML namespaces (which are supposed to enable nesting different schemas) never seem to work properly.
    FTFY.
  • Quelqu'un (unregistered) in reply to PSWorx
    PSWorx:
    dgvid:
    I've seen this kind of thing often enough that it deserves its own anti-pattern name. (And of course, the Real WTF is SOAP.)
    I think we already have that:
    Prodis a.k.a. Fernando Hamasaki de Amorim:
    This "technic" is called SOP, String Oriented Programming.
    What about "String Oriented Anti-Pattern?"
  • xmILL (unregistered)

    TRWTF is sending the schema with every message.

  • (cs) in reply to meh
    meh:
    TRWTF is that XML isn't eXtensible at all, and that XML namespaces (which are supposed to enable nesting different schemas) never seem to work properly.
    YMMV? Because I've never had a problem with it.

    The trick, BTW, is to not use any MSXML parser before version 6.

  • ClaudeSuck.de (unregistered) in reply to joe
    joe:
    Meh, we've got something better on the project I'm working on: a web service sending XML... in binary.

    Do you encode before?

    ludus: game?

  • trwtf (unregistered)

    Barely a WTF. Certainly not good enough to last for 2 days.

  • Scott (unregistered)

    Microsoft Sharepoint Web Service? They do this as well. Not a MSFT hater, but some thats a POS impl.

Leave a comment on “XML'd XML”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article