• SwordfishBob (unregistered)

    Oh lovely.. the worst of both worlds..

  • raluth (unregistered) in reply to SwordfishBob

    A colleague of mine worked on an EDI project where the 3rd-party wanted to talk xml, but couldn't grasp that adding angled brackets was not enough; so every ampersand in a description, less-than, etc, screwed it all up.

    The funny thing is that when we pointed this out, we were told that we were the first (of several) to complain, so it must be us. Obviously every company to go before us had only been to the buzzword-seminar too.

  • Why? (unregistered) in reply to raluth

     

    At least they used CDATA :) There's a schema use by the AU energy market (aseXML) which looks identical but they csv data is dumped between <CSVData></CSVData> tags - column headers and all!

  • (cs)

    Uhm, stupid question time...but the snippet looks like someone saw an XML file, didn't understand it really but tried to mimic it, and then they decided to embed CSV data at the end to give it some sort of function or purpose.   My question, how the *$%# does someone convince themselves that their customer's nerds are going to be stupid enough to fall for this?  I mean isn't blaggarant lying and iggnorance against some sort of law regarding contracts?

     

  • (cs)

    I've been looking for a while now, but for the life of me cannot find the "person.dateofbith" field in our database??

    And what's a personel and why does it have an ID? 

     

    Date of bitch: November 21, 2006 

     

  • (cs)

    No buzz compliance is complete until adding some dotnet

  • Ishai Sagi (unregistered)

    In one of my first jobs as a junior developer, I was called to a meeting with a huge customer - a bank who had templates for legal documents and they wanted to automate data entry into the templates from a mainframe, and then send it to the printer. My boss was a very good BA, and took me as the new guy who knows real programming (I went to a VB6 course) to the meeting as an advisor. They kept talking about xml this and xml that, and both me and my boss were nodding and smiling and saying "sure!". When we got out of there he told me "quick - find out what this 'xml' thingy is before the design meeting tomorrow!".

    since I had many other projects (oh, to be young again...oh, wait - I still have too many projects at the same time...damn!) I couldnt spend much time on research, but I found out the general details and came the next day to the meeting, breifing my boss "oh, its just text files with tags. like all the csv configuration files we write".

    We went inside and when the IT grilled us about how we are going to implement we displayed a great design how to parse the text out of the xml based on the tags. One of the bank IT people was surprisingly savvy and asked the obvious (well, obvious to me now) question - "why not use xpath?"

    Even though I had no idea what he was talking about, I made the response that made me the consultant that I am today. I didnt even blink.

    "well, we could use xpath, but we would lose a lot on preformance!"

     Untill today its my favorite personal WTF. Like my captcha says - perfection!

  • Cheong (unregistered)

    Tim Gallagher:
    Follow up emails were sent, but no, this was the exact and only format that would be accepted by their system.

    Judging by the above sentence, this WTF is made by lazy programmers who want to fulfill boss's request with much code alternation. 

  • Cheong (unregistered)

    Tim Gallagher:
    Follow up emails were sent, but no, this was the exact and only format that would be accepted by their system.

    Judging by the above sentence, this WTF is made by lazy programmers who want to fulfill boss's request without much code alternation. 

  • OJ (unregistered)

    This reminds me a lot of one of the lot of wtf's at the place where I did my master's thesis. We had a mass spectrometer that produced its data files in a XML/CSV format a lot like this. The difference was that those files were typically several megabytes. It took about a minute to feed one of those to DOM parser. The fun part was that you could not just throw XML parts away and use the CSV because the order of the fields could actually change.

  • moonbiter (unregistered)

    You know, as a web designer who knows enough about coding to be dangerous, many of these CodeSODs go over my head. I mean, after reading the examples and the threads I normally understand what the mistakes are, but I often feel like I am missing out on something. Being somewhat more conversant in XML, I now know what it is I was missing out on: a feeling visceral revulsion.

  • (cs) in reply to Ishai Sagi
    Anonymous:

    Even though I had no idea what he was talking about, I made the response that made me the consultant that I am today. I didnt even blink.

    "well, we could use xpath, but we would lose a lot on preformance!"

    I love you guy.

    THAT is most brilliant answer to all those **** questions i ever heard. :) Declare a patent on this answer. ;)

    Regards

  • John Hensley (unregistered)

    oh s***, it's just like the system I've been maintaining at work.

    I wish someone would respond to my resumes already.
     

  • Theo (unregistered) in reply to moonbiter

    Anonymous:
    You know, as a web designer who knows enough about coding to be dangerous, many of these CodeSODs go over my head. I mean, after reading the examples and the threads I normally understand what the mistakes are, but I often feel like I am missing out on something. Being somewhat more conversant in XML, I now know what it is I was missing out on: a feeling visceral revulsion.


    The fact that it's published on WTF helps to feel that way though. For some of the example, hardly anybody but the sheerest code fundamentalists would ever think "WTF" if they saw it in "real life". Which doesn't mean they're good, that just mean they're widespread. Come on guys, who are the lucky ones who do not work in an environment filled with potential WTF around them?

    This is a classic example of  "if people say it's bad then I'm inclined to think it's bad". Otherwise called the sheep mentality. So basically, you just realised that you lack this sheep mentality. Pretty good for you I would think.

  • JohnSmith (unregistered)

    The real WTF is that it seems someone wanted to replace a perfectly working CSV based system with XML and the programmer figured out the quickest way to do it. I've done these unneeded "upgrades" myself, each and everyone being unnecessary.

  • burned (unregistered)

    This is not funny. This is just very very sad.

    takes a deep swig

  • (cs)

    To be entirely honest, as revolting as it might seem, an XML header on a CSV stream would be welcome under some dirty-data situations. CSV is really good and one and only one thing: Dumping lots of data fast. XML is really really bad at that, and good at most of what CSV is bad at. I wouldn't combine them this way myself - I'd use some sort of signaling to separate the XML from the data so it doesn't take an age to parse - but combining them isn't a terrible idea if you're already set up for CSV data dumps and want a bit more flexibility.

    Getting your clients, that can't give you good data in the first place, to actually sign on to this scheme might be more than a little tricky though. =p 

    Thankfully I never really need much XML or CSV anymore, aside from occasional metric outputs for generating charts from.

  • (cs) in reply to JohnSmith

    Anonymous:
    The real WTF is that it seems someone wanted to replace a perfectly working CSV based system with XML and the programmer figured out the quickest way to do it. I've done these unneeded "upgrades" myself, each and everyone being unnecessary.

    I absolutely agree! Why spoil a nice CSV in the first place? I think the new XML fetish is far too widespread. From a programmers point of view, I think that XML is hard to read, hard to maintain and a pain in the a** to parse, especially with the Java parsers that are overly complicated and slow, trying to connect to the net and fetching the DTD an other obscure things that are hard to supress. XPath simplify things, but the complexity of XML just makes you want to send an SQL dump instead. And XML is not even a real standard, there are thousands of ways of putting an XML document together. I mean, come on! Saying that XML is a document standard is like saying that speech is a communication standard. Just put a Greek person next to a Chinese one and see what happens :)
     

  • Flying Codeman (unregistered)

    The WTF here is that real data has been posted.

  • Anonymouse (unregistered)

    Tim Gallagher:

    <dateformat mmddyyyy="true"/>

     That's another WTF right there...
     

  • dan s. (unregistered)
    Tim Gallagher:
    <?xml version="1.0" encoding="iso8859-1" ?>
    <import tag="1stTEST" type="data" mode="update">
    <options> 
        <dateformat mmddyyyy="true"/> 
            <notification> 
                <EMail>[email protected]</EMail> 
            </notification> 
        </options> 
        <fields>
            <field name="name" type="char" mapsto="person.data"/> 
            <field name="officeid" type="char" mapsto="custom.locationid"/> 
            <field name="startyear" type="char" mapsto="person.yearstarted"/> 
            <field name="personelid" type="int" mapsto="person.id"/> 
            <field name="dob" type="date" mapsto="person.dateofbith"/> 
            <field name="sex" type="char" mapsto="person.sex"/> 
            <field name="modified" type="date" mapsto="record.modified"/> 
        </fields> 
        <csvdata columnheaders="false"> 
    <![CDATA[
    "Jack Wade",214,2002,111012,07/04/1975,"M",02/11/2006
    "Sam Davidson",214,1999,104841,10/15/1967,"M",02/10/2006
    "Denise V Law",214,1998,104660,01/21/1971,"F",02/17/2006
    "Lisa Blake",214,1989,100987,08/01/1982,"F",01/21/2006
    "Andrew Match",214,1991,101074,12/25/1980,"M",02/28/2006
    ]]> 
        </csvdata> 
    </import>
    The real WTF is that it's not properly indented. 
    
            
    
        
    • 
        
  • 
 Jouni K. Seppänen   (unregistered)                                     
            
    
                
    This reminds me of Apple's XML representation of Property Lists. You see, OpenStep had a simple serialization format for simple data, roughly similar to JSON:
    http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Articles/OldStylePListsConcept.html#//apple_ref/doc/uid/20001012-BBCBDBJE
    Of course, this wasn't buzzword compliant, so when OpenStep became Cocoa, Apple had to change the format:
    http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Articles/XMLPListsConcept.html#//apple_ref/doc/uid/20001011-BBCBDBJE

    (See also: http://www.cakoose.com/wiki/plist_xml_is_pointless )
    
            
    
        
    • 
        
  • 
 Anonymous Perl Hacker   (unregistered)                                     
            
    
                
    This is almost like a system a fellow dev and I had to come up with.  My app was Perl over flat files, his app was Java over MySQL, and we had a third dev with PHP/MySQL.  All three products did the same thing, just in different ways, and we needed a better way to migrate customers between them.

    The only things they spoke in common were CSV and... no, not XML.  The Perl app had to run without any binary modules installed, including an XML parser, so we settled on YAML.  You'd dump your data as a CSV file, then we'd whip up these field map files in YAML.  The beautiful thing was that we could also import from a whole bunch of our competitors using the same system.  It was a beautiful, ugly hack, especially my half.  It's real fun working with tabular data when your code can't think that way.

    Of course, for every thing that we had in common in terms of sharable data, there were three things that couldn't be ground up into commonality.  This is where our ideals split - I wanted to define a more rigid common file format and write custom export code, while the other dev wanted to let the import code handle most of the heavy lifting.  Eh.  I guess I'll never find out, I left the job a year ago.
    
            
    
        
    • 
        
  • 
 PC Paul   (unregistered)                                         in reply to It's Atomic!
            
            
    
                
     It's Atomic!:
     
    I've been looking for a while now, but for the life of me cannot find the "person.dateofbith" field in our database??
    And what's a personel and why does it have an ID?
     
    That's anonymisation, that is ;-)
    
            
    
        
    • 
        
  • 
 B   (unregistered)                                     
            
    
                
    Why did Lisa got her office when she was 7 while Andrew had to wait until his eleven birthday? Nepotism again?
    
            
    
        
    • 
        
  • 
 leeg   (unregistered)                                         in reply to Jouni K. Seppänen
            
            
    
                
     Anonymous:
    This reminds me of Apple's XML representation of Property Lists. You see, OpenStep had a simple serialization format for simple data, roughly similar to JSON:
    http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Articles/OldStylePListsConcept.html#//apple_ref/doc/uid/20001012-BBCBDBJE
    Of course, this wasn't buzzword compliant, so when OpenStep became Cocoa, Apple had to change the format:
    http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Articles/XMLPListsConcept.html#//apple_ref/doc/uid/20001011-BBCBDBJE

    (See also: http://www.cakoose.com/wiki/plist_xml_is_pointless )
    

    And they've since changed - again - to using a binary format by default, because XML "looses the preformance".  Of course, they'll soon observe that the binary format is not readily human-readable and go to a serialised format...
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to Cheong
            
            
    
                
     Anonymous:
     Tim Gallagher:
    Follow up emails were sent, but no, this was the exact and only format that would be accepted by their system.
    Judging by the above sentence, this WTF is made by lazy programmers who want to fulfill boss's request with much code alternation. 
    No, it's made by a smart programmer who has just been handed a "specification" that said something like: "The file format must be XML", where that was the only "specification" of the file format, and asking for further clarification just got blank stares. The correct response to this non-specification is to take your current file format and wrap it in a CDATA block - getting the requirement satisfied with a minimum of effort is what the job is all about.
    Next time, they might learn to write a proper specification. The programmer can do nothing to correct the fact that management has already ruined the current specification by not leaving the problem to the people who knew how to handle it.
    If more people did this, we might finally be able to disabuse people of this notion that XML is some kind of "universal adaptor", magically making different things work together (it doesn't). The way I like to explain it to people is like this: XML is like a language. Saying "do it in XML" is just like saying "do it in Sanskrit" - it doesn't tell you anything about how to do it, and furthermore it's choosing a language that is understood by none of the current components of our system. Now can we turn this into a real requirement, or is it just a checkbox that nobody cares about?
    If it's a checkbox, that is what CDATA is for. This sort of nonsense happens a lot in government contracts and similar organisations - the spec sheet says "must use X", but X isn't actually needed and was just added by some bureaucrat who wanted to justify their own existence, so the right thing to do is to pay lip service to the item and get on with something useful.
    
            
    
        
    • 
        
  • 
 Flying Codeman   (unregistered)                                         in reply to asuffield
            
            
    
                
     asuffield:
     The correct response to this non-specification is to take your current file format and wrap it in a CDATA block - getting the requirement satisfied with a minimum of effort is what the job is all about.
    Sigh.
    I remember once having read something about "Professional Ethics" and "High Standards" in the SoftDev industry. Must have been written before 1970.
     
    Captcha: null. How appropriate.
     
    
            
    
        
    • 
        
  • 
 hc   (unregistered)                                     
            
    
                
     Tim Gallagher:
    Today's Code Snippet comes from Rob O.  Rob was working in a company (as a contractor) on different projects for almost a year before he was asked to sit in on a meeting with two vendors and two business analysts.  Rob failed to notice during the discussion one of the third parties furiously writing notes every time they were asked about XML.
    

    They had not gotten very far with the technical details of the project, but the business analysts knew what they wanted.  Buzz-word compliance.  The buzz-word: XML.
    When Rob was not being ignored like a third-grade class-president (I have no idea what that means) he was being asked if his system would be able to handle sending and receiving the various files and messages as XML which, of course, it could.
    

    What Rob failed to notice during the discussion was how one of the third parties was furiously writing notes every time they were asked about XML. "Yes," they would reply with an enthusiastic nod, "Our system will handle XML."
    ...
     
     
    Brought to you by Department of Redundancy Dept. 
    
            
    
        
    • 
        
  • 
 David   (unregistered)                                     
            
    
                
    It's actually not that bad (it is legal XML, after all).
    The real WTF would be if, when they say "this is the exact and only format that will be accepted" they mean that you can't change the format of the CSV data section, i.e. you can't change the metadata in the fields element.
    If the target system is able to handle different formats (e.g. alternative date formats, additional columns) then it's a big improvement over a fixed CSV import format. However, I suspect this is not the case and the whole of the <options> and <fields> sections are redundant.
    
            
    
        
    • 
        
  • 
 Mikeyd   (unregistered)                                         in reply to WIldpeaks
            
            
    
                
     WIldpeaks:
    No buzz compliance is complete until adding some dotnet
    Java is even more of a buzzword.
            
    
        
    • 
        
  • 
 Mikeyd   (unregistered)                                         in reply to Flying Codeman
            
            
    
                
     Anonymous:
     asuffield:
     The correct response to this non-specification is to take your current file format and wrap it in a CDATA block - getting the requirement satisfied with a minimum of effort is what the job is all about.
    Sigh.
    I remember once having read something about "Professional Ethics" and "High Standards" in the SoftDev industry. Must have been written before 1970.
     
    Captcha: null. How appropriate.
     
    It *is* the ethical thing to do, it's better for everyone in the long run. Captcha: enterprisey
            
    
        
    • 
        
  • 
 l0b0   (unregistered)                                         in reply to asuffield
            
            
    
                
     asuffield:
    This sort of nonsense happens a lot in government contracts and similar organisations - the spec sheet says "must use X", but X isn't actually needed and was just added by some bureaucrat who wanted to justify their own existence, so the right thing to do is to pay lip service to the item and get on with something useful.
    

    It often seems like this kind of problem is caused by a form of premature optimization - A business requirement is stated (e.g., "must be portable"), and one of the people involved vaguely remembers an article in <IT management magazine> where technology X is shown as the silver bullet for a whole class of problems, seemingly overlapping with the problem at hand. Fast forward a few weeks, and you've got a spec that focuses on the technology, not the solution.
     
    
            
    
        
    • 
        
  • 
 david   (unregistered)                                     
            
    
                
    The real WTF is that there's no code in the "Code Snippet of the Day."
    
            
    
        
    • 
        
  • 
    (cs)                                     
            
    
                
    Ah, I love it. Wrap a piece of shit up in a pretty box, and claim that it's a valuable gift. Open it up and it's still just a pile of shit.
    
            
    
        
    • 
        
  • 
    (cs)                                     
            
    
                
    Damn - that's a nice way to have a 1:100 compression ratio on XML grin
    
            
    
        
    • 
        
  • 
    (cs)                                     
            
    
                
    <geez/>
    People just don't get it do they?!  It's kinda like EDI everyone has their own "special" version of an EDI document that they use to insure their edi system is "theirs".
     <idiots are everywhere they keep following me around/>
    
            
    
        
    • 
        
  • 
 Right Said Fred   (unregistered)                                         in reply to Ishai Sagi
            
            
    
                
     Anonymous:
    Even though I had no idea what he was talking about, I made the response that made me the consultant that I am today. I didnt even blink. 
    "well, we could use xpath, but we would lose a lot on preformance!"

    So you're not a very good consultant.  If you don't know the answer to something, just say you don't know, but you'll find out.  This has been my standard response for years.  My customers appreciate the honesty, and know I'm not going to lie to them.  They in turn trust me more and its easier for me to get the job I was brought in to do.  

    Lying to your customers will come back and bite you hard.  It's not a question of if, it's a question of when, and how much money you're going to lose.

    
            
    
        
    • 
        
  • 
    (cs)                                     
            
    
                
    It should have looked like this...
    

     
    

    <?xml version="1.0" encoding="iso8859-1" ?>
    
<csvdata> 
    
<![CDATA[
    
name,officeid,startyear,personelid,dob,sex,modified
    
"Jack Wade",214,2002,111012,07/04/1975,"M",02/11/2006
    
"Sam Davidson",214,1999,104841,10/15/1967,"M",02/10/2006
    
"Denise V Law",214,1998,104660,01/21/1971,"F",02/17/2006
    
"Lisa Blake",214,1989,100987,08/01/1982,"F",01/21/2006
    
"Andrew Match",214,1991,101074,12/25/1980,"M",02/28/2006
    
]]> 
    
</csvdata> 
    

    

     
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to Ishai Sagi
            
            
    
                
     Anonymous:
    Even though I had no idea what he was talking about, I made the response that made me the consultant that I am today. I didnt even blink. 
    "well, we could use xpath, but we would lose a lot on preformance!"
     
    You are my new hero. 
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to asuffield
            
            
    
                
     asuffield:
     Anonymous:
     Tim Gallagher:
    Follow up emails were sent, but no, this was the exact and only format that would be accepted by their system.
    Judging by the above sentence, this WTF is made by lazy programmers who want to fulfill boss's request with much code alternation. 
    No, it's made by a smart programmer who has just been handed a "specification" that said something like: "The file format must be XML", where that was the only "specification" of the file format, and asking for further clarification just got blank stares. The correct response to this non-specification is to take your current file format and wrap it in a CDATA block - getting the requirement satisfied with a minimum of effort is what the job is all about.
    Next time, they might learn to write a proper specification. The programmer can do nothing to correct the fact that management has already ruined the current specification by not leaving the problem to the people who knew how to handle it.
    If more people did this, we might finally be able to disabuse people of this notion that XML is some kind of "universal adaptor", magically making different things work together (it doesn't). The way I like to explain it to people is like this: XML is like a language. Saying "do it in XML" is just like saying "do it in Sanskrit" - it doesn't tell you anything about how to do it, and furthermore it's choosing a language that is understood by none of the current components of our system. Now can we turn this into a real requirement, or is it just a checkbox that nobody cares about?
    If it's a checkbox, that is what CDATA is for. This sort of nonsense happens a lot in government contracts and similar organisations - the spec sheet says "must use X", but X isn't actually needed and was just added by some bureaucrat who wanted to justify their own existence, so the right thing to do is to pay lip service to the item and get on with something useful.
    Oh please.  As software developers, our job is to give our customers what s/he wants, which is usually very different from what s/he asks for.  
    Our customers don't have the knowledge/abilities to write a perfect spec.  A big part of our jobs is to elucidate what they want - this is the toughest part of software development, but it is critical.  In this case, they wanted data to be interchanged using XML, probably because other components of the system were also using XML.  This is simply a lazy solution, and is clearly not what the customer wanted.
    
            
    
        
    • 
        
  • 
 JoeB   (unregistered)                                     
            
    
                
    I have to add that I see a lot of people thinking that XML is great for all data transfers.  This is true if you are doing small amounts of transactional data transfers.  But as soon as you try and send large amounts of data then it really is better to use csv or fixed width because of the speed to import the data.
    
            
    
        
    • 
        
  • 
 Tim   (unregistered)                                         in reply to Obfuscator
            
            
    
                
     Obfuscator:
     
     Anonymous:
    The real WTF is that it seems someone wanted to replace a perfectly working CSV based system with XML and the programmer figured out the quickest way to do it. I've done these unneeded "upgrades" myself, each and everyone being unnecessary.
     
    I absolutely agree! Why spoil a nice CSV in the first place? I think the new XML fetish is far too widespread. From a programmers point of view, I think that XML is hard to read, hard to maintain and a pain in the a** to parse, especially with the Java parsers that are overly complicated and slow, trying to connect to the net and fetching the DTD an other obscure things that are hard to supress. XPath simplify things, but the complexity of XML just makes you want to send an SQL dump instead. And XML is not even a real standard, there are thousands of ways of putting an XML document together. I mean, come on! Saying that XML is a document standard is like saying that speech is a communication standard. Just put a Greek person next to a Chinese one and see what happens :) 
     
     
    Yeah, but CSV is not a data standard either. At least in the minds of many people I've worked with. I just worked with a guy who converted all of his CSV files to TSV (tab separated not tilde), because of the "quote problem". The guy didn't realize that the "quote problem" had been solved decades ago. Of course he probably wouldn't have had the problem in the first place if he hadn't decided to roll his own CSV parser.
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to rmr
            
            
    
                
    I agree that we need to help our customers, but I have seen many cases where the product managers don't listen or ask for advice from the developers before they allocate time to a project.    This could of been one of those issues. 
    This is exactly the kind of trash that I would provide if I had other more important things to work on and they didn't consult with me.    
    There are also many situations where we are forced to give half measures just to meet deadlines knowing full well that it will come back to us.  It is all smoke and mirrors sometimes.    There is no such thing as the perfect dev house anyway (most places are not even dev houses to begin with.
    This xml document is very simple to work with in .net.  You can just use the split function just like you would any other csv file.  It is a quick and dirty workaround that doesn't cause many issues anyway.
     
     
     
    
            
    
        
    • 
        
  • 
 Dear Lord   (unregistered)                                         in reply to raluth
            
            
    
                
     Anonymous:
     
    A colleague of mine worked on an EDI project where the 3rd-party wanted to talk xml, but couldn't grasp that adding angled brackets was not enough; so every ampersand in a description, less-than, etc, screwed it all up.
    The funny thing is that when we pointed this out, we were told that we were the first (of several) to complain, so it must be us. Obviously every company to go before us had only been to the buzzword-seminar too.
    That 3rd-party isn't (or didn't get gobbled up by) a company that ends with an IS, starts with an I, and has a big NOV in the middle, is it? ;-)
    captcha equals "whiskey" - as in, 'whis-key will get me outta this crazy house?'
    
            
    
        
    • 
        
  • 
 Sam Thornton   (unregistered)                                     
            
    
                
    It's deja vu all over again. I developed an online banking application a few years ago where the backend output that had to be dealt with was XML that wrapped space-delimited screen files from a legacy COBOL-based system in CDATA tags. The XML portion was not only laughable, the vendor had a nasty habit of changing some of the specs every few months for no apparent reason other than to generate "upgrade" revenue.
    
            
    
        
    • 
        
  • 
 Doo   (unregistered)                                         in reply to Mikeyd
            
            
    
                
     Anonymous:
     WIldpeaks:
     
    No buzz compliance is complete until adding some dotnet
    Java is even more of a buzzword.
    I like Apple Solaris myself.  Mmmm, apples.
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to moonbiter
            
            
    
                
     Anonymous:
    You know, as a web designer who knows enough about coding to be dangerous, many of these CodeSODs go over my head. I mean, after reading the examples and the threads I normally understand what the mistakes are, but I often feel like I am missing out on something. Being somewhat more conversant in XML, I now know what it is I was missing out on: a feeling visceral revulsion.
    

    I'm still laughing at your comment... glad I could help. 
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to david
            
            
    
                
     Anonymous:
    The real WTF is that there's no code in the "Code Snippet of the Day."
    Shhhhh! 
    
            
    
        
    • 
        
  • 
    (cs)                                         in reply to Flying Codeman
            
            
    
                
     Anonymous:
    The WTF here is that real data has been posted.
     
    The data was sanitized before posting. 
    
            
    
        
    • 
    


            


            
  • 



            


                

                
Leave a comment on “XML vs CSV : The Choice is Obvious”


                
Log In or post as a guest


                
                
Replying to comment #:


                

                    
                    Log Out
                


                

                    
                


                





                

                    
                


            


            
« Return to Article