• Ripper the Non-Believer (unregistered) in reply to Ion9

    I love the new word coinage. Blaggarant. It's good!

  • (cs) in reply to Ripper the Non-Believer

    Anonymous:
    I love the new word coinage. Blaggarant. It's good!

    Ha Ha  Ha Ha Ha Ha.

  • JD (unregistered) in reply to david
    Anonymous:
    The real WTF is that there's no code in the "Code Snippet of the Day."
    eh? XML is code
  • Anonymous (unregistered) in reply to JD

    Any chance of someone posting what a valid XML solution might look like?  I am XML ignorant, and though I get some of the complaints with this snippet, it would be nice to have a better solution to compare to.

  • Cody (unregistered) in reply to Ion9
    Ion9:

    I mean isn't blaggarant lying and iggnorance against some sort of law regarding contracts?

     

    It's not a lie to call that XML.  That's perfectly formed XML that will pass any legal sniff test. 

  • (cs) in reply to Theo
    Anonymous:

    Come on guys, who are the lucky ones who do not work in an environment filled with potential WTF around them?

     

    /me raises hand...   sheepishly.... 

  • (cs) in reply to RevMike

    It should have looked like this:

     

    <?xml version="1.0"?>
    <?mso-application progid="Excel.Sheet"?>
    <Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet"
     xmlns:o="urn:schemas-microsoft-com:office:office"
     xmlns:x="urn:schemas-microsoft-com:office:excel"
     xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet"
     xmlns:html="http://www.w3.org/TR/REC-html40">
     <DocumentProperties xmlns="urn:schemas-microsoft-com:office:office">
      <LastAuthor>Newfweiler</LastAuthor>
      <Created>2006-11-21T17:00:47Z</Created>
      <Version>11.8107</Version>
     </DocumentProperties>
     <ExcelWorkbook xmlns="urn:schemas-microsoft-com:office:excel">
      <WindowHeight>12525</WindowHeight>
      <WindowWidth>18075</WindowWidth>
      <WindowTopX>240</WindowTopX>
      <WindowTopY>120</WindowTopY>
      <ProtectStructure>False</ProtectStructure>
      <ProtectWindows>False</ProtectWindows>
     </ExcelWorkbook>
     <Styles>
      <Style ss:ID="Default" ss:Name="Normal">
       <Alignment ss:Vertical="Bottom"/>
       <Borders/>
       <Font/>
       <Interior/>
       <NumberFormat/>
       <Protection/>
      </Style>
      <Style ss:ID="s21">
       <NumberFormat ss:Format="Short Date"/>
      </Style>
     </Styles>
     <Worksheet ss:Name="test">
      <Table ss:ExpandedColumnCount="7" ss:ExpandedRowCount="5" x:FullColumns="1"
       x:FullRows="1">
       <Column ss:Index="5" ss:AutoFitWidth="0" ss:Width="57.75"/>
       <Row>
        <Cell><Data ss:Type="String">Jack Wade</Data></Cell>
        <Cell><Data ss:Type="Number">214</Data></Cell>
        <Cell><Data ss:Type="Number">2002</Data></Cell>
        <Cell><Data ss:Type="Number">111012</Data></Cell>
        <Cell ss:StyleID="s21"><Data ss:Type="DateTime">1975-07-04T00:00:00.000</Data></Cell>
        <Cell><Data ss:Type="String">M</Data></Cell>
        <Cell ss:StyleID="s21"><Data ss:Type="DateTime">2006-02-11T00:00:00.000</Data></Cell>
       </Row>
       <Row>
        <Cell><Data ss:Type="String">Sam Davidson</Data></Cell>
        <Cell><Data ss:Type="Number">214</Data></Cell>
        <Cell><Data ss:Type="Number">1999</Data></Cell>
        <Cell><Data ss:Type="Number">104841</Data></Cell>
        <Cell ss:StyleID="s21"><Data ss:Type="DateTime">1967-10-15T00:00:00.000</Data></Cell>
        <Cell><Data ss:Type="String">M</Data></Cell>
        <Cell ss:StyleID="s21"><Data ss:Type="DateTime">2006-02-10T00:00:00.000</Data></Cell>
       </Row>
       <Row>
        <Cell><Data ss:Type="String">Denise V Law</Data></Cell>
        <Cell><Data ss:Type="Number">214</Data></Cell>
        <Cell><Data ss:Type="Number">1998</Data></Cell>
        <Cell><Data ss:Type="Number">104660</Data></Cell>
        <Cell ss:StyleID="s21"><Data ss:Type="DateTime">1971-01-21T00:00:00.000</Data></Cell>
        <Cell><Data ss:Type="String">F</Data></Cell>
        <Cell ss:StyleID="s21"><Data ss:Type="DateTime">2006-02-17T00:00:00.000</Data></Cell>
       </Row>
       <Row>
        <Cell><Data ss:Type="String">Lisa Blake</Data></Cell>
        <Cell><Data ss:Type="Number">214</Data></Cell>
        <Cell><Data ss:Type="Number">1989</Data></Cell>
        <Cell><Data ss:Type="Number">100987</Data></Cell>
        <Cell ss:StyleID="s21"><Data ss:Type="DateTime">1982-08-01T00:00:00.000</Data></Cell>
        <Cell><Data ss:Type="String">F</Data></Cell>
        <Cell ss:StyleID="s21"><Data ss:Type="DateTime">2006-01-21T00:00:00.000</Data></Cell>
       </Row>
       <Row>
        <Cell><Data ss:Type="String">Andrew Match</Data></Cell>
        <Cell><Data ss:Type="Number">214</Data></Cell>
        <Cell><Data ss:Type="Number">1991</Data></Cell>
        <Cell><Data ss:Type="Number">101074</Data></Cell>
        <Cell ss:StyleID="s21"><Data ss:Type="DateTime">1980-12-25T00:00:00.000</Data></Cell>
        <Cell><Data ss:Type="String">M</Data></Cell>
        <Cell ss:StyleID="s21"><Data ss:Type="DateTime">2006-02-28T00:00:00.000</Data></Cell>
       </Row>
      </Table>
      <WorksheetOptions xmlns="urn:schemas-microsoft-com:office:excel">
       <Selected/>
       <ProtectObjects>False</ProtectObjects>
       <ProtectScenarios>False</ProtectScenarios>
      </WorksheetOptions>
     </Worksheet>
    </Workbook>

     

  • Not telling (unregistered) in reply to Ottokar
    [image] 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

    "Why don't you use XPATH" is not a **** (dumb?) question. Just as much as "Why don't you use a SQL query?". In many cases it makes no sense to use XML if you're not taking advantage of XSLT, XPATH, etc. If you care about performance so much, don't use XML.

    Sometimes coming across like an ***hat is better than coming across as an ignorant ***hat, I'll give you that.

  • Munky (unregistered)

    I've had almost the exact opposite, one of our contracting groups had a timekeeping system that output in csv, but the last column in the csv was a full xml document containing all of the data contained in that row, sans the xml column of course.

     Well before I got there the timekeeping system we have would parse xml, and some two geniuses got together when they picked up the contractors and decided on using csv as the exchange medium.

    What was idiotic about the whole thing, the contractors timekeeping system was written to output xml first, and was altered to output csv.
     

  • kocka (unregistered)

    not that horribly bad, maybe transformable it with an xslt to something more firendly format :)
     

  • (cs) in reply to Anonymous
    Anonymous:
    Any chance of someone posting what a valid XML solution might look like?  I am XML ignorant, and though I get some of the complaints with this snippet, it would be nice to have a better solution to compare to.


    Here's an example of what they could have done. Pretend that I left the options tag part intact, as that's actually not that bad.

    <people>
      <user>
        <name>Jack Wade</name>
        <officeID>214</officeID>
        <startingDate format="mm/dd/yyyy">01/02/2003</start>
        <personelID>111012</personelID>
        <DOB format="mm/dd/yyyy">07/04/1975</DOB>
        <sex>Male</sex>
        <lastModified format="mm/dd/yyyy">02/11/2006</lastModified>
        </user>
        ... other users go here
    </people>

    Bear in mind that XML is very freeform. A good XML primer is at W3Schools ( http://www.w3schools.com/xml/default.asp ).

    The idea is that with XML, the data pretty much describes itself. You can look at an XML document and know exactly what the hell is going on, as long as the tags and such are descriptively named such that you can understand it. What these guys did, instead, is take a CSV file, throw it in, and tack on a few "descriptors" in another node. Basically, they took a CSV file and wrapped XML around it so that they could say they were using "XML"

  • Holli (unregistered)

    Let me tell you a story. I work for a public authority of the Saarland (a state of germany). We were used to exchange data with our superior authority in Berlin once quarter. This was a mostly painless process, we used CSV and fixed length EDI files. Then some bighead decided two years ago it would be chicque and politically desirable (authorities like to look modern, you know) to replace the established process by a whole new toolset and, of course, using XML.

    Result:

    • 50 Megs of tabular date mutated to 3-4 Gig of XML
    • runtime increased from 15 Minutes to many, many hours
    • confusion about the handling of, and bugs in the new tools and programs caused a processing delay of months

    Worst of all: I am in charge of that crap.

    Holli 

  • Erzengel (unregistered) 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.

    I think you're missing the point. This was a third party. If you're using XML for extra-company communications, you should use XML in its expected format. It's one thing to WTF in intra-company programs, but WTFing in the exposed portions of your product, the parts that clients are supposed to use, is another thing entirely.

  • mjparme (unregistered)

    I bet their database has comma-delimited fields in it too!

  • (cs) in reply to JD

    Anonymous:
    Anonymous:
    The real WTF is that there's no code in the "Code Snippet of the Day."
    eh? XML is code

    XML is markup, not code.
     

  • (cs) in reply to Ishai Sagi
    Anonymous:

    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!

    Bravo. Justifying design decisions by appealing to performance. The last resort of the incompetent. Also known as: "turbo-might manure-ver".

     I'll have to remember that the next time I'm in over my head. I should also remember to consider this possibility the next time I hear someone use that excuse on me. The bluff can be called by asking "what performance benchmarks have you run in a production environment to justify this decision"?

    I'm impressed that you had the guts to try this and even more impressed that you got away with it. Well done.

  • Anon (unregistered) in reply to newfweiler
    newfweiler:

    It should have looked like this:

     

    <?xml version="1.0"?>
    <?mso-application progid="Excel.Sheet"?>
    ...

    That's too painfully familiar.  Try exporting a defect report from Rational ClearQuest and you get something like that.  Except it's so bad Excel can't even import it.  'Scuse me while I go cry again.

  • Martin (unregistered) in reply to OneFactor

    The correct answer to  "what performance benchmarks have you run in a production environment to justify this decision"? is:

     

    I am sorry, but i implemented the benchmark in dot net 2.0 and the license for dot net 2.0 prevent me from giving you any benchmark data.  (And then they say there is no use for stupid licenses :}

     

  • Corporate Cog (unregistered) in reply to Ishai Sagi
    Anonymous:

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

    I'll have to remember that.  Just make up a new word (like preformance) and people won't dare admit they don't know what it means.  Brillant!

  • jones (unregistered) in reply to WIldpeaks
    WIldpeaks:

    It is by caffeine alone I set my mind in motion,
    It is by the beans of Java that thoughts acquire speed,
    The hands acquire shaking, the shaking becomes a warning,
    It is by caffeine alone I set my mind in motion.

     

    OMG that is the best signature ever.  brings me back to the days of watching dune while drinking vast amounts of psylocybin tea........... 

     

    yeah totally off topic,  but bad xml is more the norm than good signatures..... 

  • Corporate Cog (unregistered) in reply to JoeB

    Anonymous:
    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.

    Unless speed isn't an issue; then XML may be better because you don't have to write any new code to parse it (unless, on the other hand, you already have libraries for csv / fixed width).  And if you need to validate the data, you can add a schema (although it will be even slower).

    On balance, I think XML gets a bad rap on this forum.
     

  • anonymous (unregistered) in reply to JD

    Anonymous:
    Anonymous:
    The real WTF is that there's no code in the "Code Snippet of the Day."

    eh? XML is code

    The Real WTF is Windows, so on windows Internet Explorer open XML files with a warning and the yellow banner with some random words about active-x damaging your computer and you need to be protected from XML files.

     

     

  • Jon W (unregistered) in reply to Ion9

    I believe they totally understood XML. However, I also believe they already had an existing infrastructure for CSV files, and they didn't want to change that infrastructure. Thus, they married a (quite reasonable) XML header to an (already existing) CSV parser, and the problem was solved in time for lunch. Actually doing XML schema parsing would take a long time, and thus reduce the profit on the sale. It's the Enterprise way, from what I'm led to understand!

  • (cs)

    <hee hee/>

    I once inherited a project that some LAWYER wrote <wtf #1 /> that stored an xml file in a database *FIELD* <wtf #2> which led to "hey how can I run a report on that xml file that's in that field <wtf #3>

    needless to say a rewrite fixed this problem.

  • Jon W (unregistered) in reply to Volmarias

    Tags are for things there are many of. Attributes are for things there are one (or zero) of. Thus, you'd probably just want something like:

    <people dateFormat='mm/dd/yyyy'>
      <user  name='Jack Wade' officeID='214' startingDate='01/02/2003' personnelID='111012' DOB='07/04/1975' sex='M' lastModifier='02/11/2006' />
    </people>



     

  • antred (unregistered) in reply to Corporate Cog
    Anonymous:

    Unless speed isn't an issue; then XML may be better because you don't have to write any new code to parse it (unless, on the other hand, you already have libraries for csv / fixed width).  And if you need to validate the data, you can add a schema (although it will be even slower).

    On balance, I think XML gets a bad rap on this forum.

     

    True. I think XML is a good option if you have to save nested data structures in non-binary files. Of course once your data structures reach a certain complexity or your XML files grow too large, you may be better off inventing your own file format or using a database system.

  • (cs)

    This is no wtf, this is magnificent!  Obviously some passive-agressive developer had enough of his pointy haired boss insisting on xml, and gave him this to shut him up. 

    At least, thats what I choose to believe.

  • Greytone (unregistered) in reply to Ghost Ware Wizard
    Ghost Ware Wizard:

    <hee hee/>

    I once inherited a project that some LAWYER wrote <wtf #1 /> that stored an xml file in a database *FIELD* <wtf #2> which led to "hey how can I run a report on that xml file that's in that field <wtf #3>

    needless to say a rewrite fixed this problem.

     

    I have come across situations where storing XML in a database field makes sense. A record recycle system that I worked on several years ago held records that had been *deleted* from the system as XML in a database field. This removed the need to have hundreds of specific recycled record tables. So its not quite as big a WTF as you would make it out to be. Of course there is no excuse for lawyers writing software.

  • Anonymous (unregistered) in reply to leeg
    Anonymous:
    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...

    Its already a serialized format. That's actually all plists are, serialized objects. The binary format takes up less space on disk and is faster to process which is why its the default format for programs now, however the file format difference is completely transparent to any well behaved program.

    As far as Human Readable goes, there's a command line tool called plutil which allows conversion from the binary format to the XML format and back. (ex. plutil -convert xm1 myfile.plist) There's also a plist editor that comes with the OS X developer tools.

  • Anonymous (unregistered) in reply to John Bigboote
    John Bigboote:

    Anonymous:
    Anonymous:
    The real WTF is that there's no code in the "Code Snippet of the Day."
    eh? XML is code

    XML is markup, not code.


    What exactly would you call OpenLazlo or XSLT then? XML may be code.

    Captcha: clueless
  • (cs) in reply to Tim

    Anonymous:

    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.

     

    The trouble(*) is that the "quote problem" has multiple solutions, each of which fails on a different subset of inputs.  TSV's failure set (values containing tabs) is considerably smaller.

     

    * Troubleshooter (n.) - Someone who finds trouble and shoots it.

     

  • (cs) in reply to OneFactor

    OneFactor:

    Bravo. Justifying design decisions by appealing to performance. The last resort of the incompetent. Also known as: "turbo-might manure-ver".

     

    How is that FizzbinSQL project coming along, anyhow?

     

  • (cs) in reply to l0b0

    This behavior on requirements goes both ways though. Did the development group ever contact their customers to let them know: "Hey, this is how we're expecting to fulfill your requirement, are you OK with this design?"

    Honestly, would you build a brand new house costing $100k+ and never once inspect the design plans, how the construction was going, and whether they were meeting your expectations? Would half the builders just build a piece of shit and cover it up with drywall and paint if you never were involved in the build process? You bet your butt they would!

    Yes, it's a nice WTF, but there've been better ones posted on this board than this one. I blame the Business and the 3rd Party software vendor on this one. Just typical, bad project management though - and there's a lot of poor leadership of projects, processes, and entire businesses going 'round these days...
     

  • Corporate Cog (unregistered) in reply to Jon W
    Anonymous:

    Tags are for things there are many of. Attributes are for things there are one (or zero) of.

    I used to think so, but was shown wrong.  Attributes are by strong convention to be used only for metadata.   Reference this excellent resource.

  • (cs) in reply to Anonymous
    Anonymous:
    John Bigboote:

    Anonymous:
    Anonymous:
    The real WTF is that there's no code in the "Code Snippet of the Day."
    eh? XML is code

    XML is markup, not code.


    What exactly would you call OpenLazlo or XSLT then? XML may be code.

    Captcha: clueless

     

    Point taken. I guess I should have said THIS XML is markup, not code. So I stand by the OP's statement. 

  • PseudoNoise (unregistered) in reply to Tim
    Tim:

    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.

    Wait till he finds out about the "tab problem" in TSV.
     

  • tamosius (unregistered) in reply to Ishai Sagi
    Anonymous:

    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!

    Thanks to people like you, we have this site that entertains me daily...!

    I'm pretty sure you still produce those WTF moments daily.. why? Because it's too difficult to recognize for you that you don't know something... it's not much different from cheating...
  • - (unregistered) in reply to Corporate Cog
    Anonymous:

    Anonymous:
    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.

    Unless speed isn't an issue; then XML may be better because you don't have to write any new code to parse it (unless, on the other hand, you already have libraries for csv / fixed width).  And if you need to validate the data, you can add a schema (although it will be even slower).

    On balance, I think XML gets a bad rap on this forum.
     

    When you have a library, like http://ostermiller.org/utils/CSV.html , parsing CSV is very simple. The library takes care of quoting, double quotes, escapes...

    while(fields = parser.getLine()) {
        System.out.println(fields[0]);
    }
    
    If you have a job where you have to export data, you should ask yourself "What's stopping me from using TSV?". I like XML, and it's a good choice for many tasks, but in some cases (as in simple data exports) TSV is both easier (with a library) and faster.
  • tamosius (unregistered) in reply to John Bigboote
    John Bigboote:
    Anonymous:
    John Bigboote:

    Anonymous:
    Anonymous:
    The real WTF is that there's no code in the "Code Snippet of the Day."
    eh? XML is code

    XML is markup, not code.


    What exactly would you call OpenLazlo or XSLT then? XML may be code.

    Captcha: clueless

     

    Point taken. I guess I should have said THIS XML is markup, not code. So I stand by the OP's statement. 

     Still.. markup... that marks-up code :-)
     

  • Anony Moose (unregistered) in reply to rmr

    rmr:
    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.

    Maybe, but what we tend to do is give them what they'll pay for, which is often neither what they want nor what any sane person would need.  ;)


    rmr:
    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.

    That's why the spec writing is done after the analysis phase, and is updated in an iterative process driven by intelligent people who're cooperating to build a useful product.

    In theory.

    In reality, either or both side are held down by idiots and office politics means that the average customer is focussed on building their own office empire, rather than meeting real needs of the poor bastards who're actually going to beusing the software. Isn't life fun?


    rmr:
    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.

    The guy with the chequebook is the customer. The guy in a cubicle with a workstation is the one who needs to get data from assorted locations. Meeting the needs of the user often doesn't satisfy the desires of the guy who won't personally use the damn thing.

    Doesn't matter if it's software or selecting a catering company - the VP dines at a 5-star restaurant, and doesn't care if the replacable employees get fed stale tuna every day, no matter how much the catering company broker may have high personal standards.

    The real WTF is the idea that leaving the oceans was a good idea.  ;)

  • Franz Kafka (unregistered) in reply to Tim
    Anonymous:

    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.

     

    The quote problem is a fundamental design flaw - you've got two separate standards for escaping things and the edge cases caused by this complexity mean that there are lots of incompatible csv standards, so you may as well chuck it all and start over.

    I propose the following standard:

    1. pipe separated values, one row per line

    2. all escaping is done with \, so \r, \n, \p (pipe) and \" behave as expected

    3. any line starting with | is a meta line. It can describe column headings or author info or whatever you like. Not much defined here

     

    The problem, as always, is getting people to agree on the same thing. 

  • (cs) in reply to Jouni K. Seppänen

    Anonymous:
    This reminds me of Apple's XML representation of Property Lists.


    Which are used as serialisation format.

    A hint for people who want to preserve their sanity: Never EVER look at the native OmniOutliner 2 files; only look at the exported "XML" files which at least attempt at being sane. (No idea if 3.x has cleaned up their act.)

    Basically the files are plists. With bazillion pieces of gunk you don't need if you are not interested, in intimate detail, how OmniOutliner physically stores its objects. With text in the outline in RTF format. Mysterious Binary Blobs. And the whole thing wrapped in XML.
     

  • anony-mouse (unregistered) in reply to tamosius
    Anonymous:
    John Bigboote:
    Anonymous:
    John Bigboote:

    Anonymous:
    Anonymous:
    The real WTF is that there's no code in the "Code Snippet of the Day."
    eh? XML is code

    XML is markup, not code.


    What exactly would you call OpenLazlo or XSLT then? XML may be code.

    Captcha: clueless

     

    Point taken. I guess I should have said THIS XML is markup, not code. So I stand by the OP's statement. 

     Still.. markup... that marks-up code :-)
     

    No. 

    captcha: genius
     

  • (cs) in reply to Holli
    Anonymous:

    Let me tell you a story. I work for a public authority of the Saarland (a state of germany). We were used to exchange data with our superior authority in Berlin once quarter. This was a mostly painless process, we used CSV and fixed length EDI files. Then some bighead decided two years ago it would be chicque and politically desirable (authorities like to look modern, you know) to replace the established process by a whole new toolset and, of course, using XML.

    Result:

    • 50 Megs of tabular date mutated to 3-4 Gig of XML
    • runtime increased from 15 Minutes to many, many hours
    • confusion about the handling of, and bugs in the new tools and programs caused a processing delay of months

    Worst of all: I am in charge of that crap.

    Holli 

    <font size="+1">I</font>f it's not broken, don't fix it!
  • Beeb (unregistered) in reply to hc

    If Rob failed to notice these things, how could have he related them to anybody else?

    ------------------------- 

    "Are you asleep?"

    "Yes."

     

     

     

  • Beeb (unregistered) in reply to hc
    Anonymous:
    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. 

     

     

    If Rob failed to notice these things, how could have he related them to anybody else?

    ------------------------- 

    "Are you asleep?"

    "Yes."

     

     

  • Chris Travers (unregistered) in reply to notromda
    notromda:
    Anonymous:

    Come on guys, who are the lucky ones who do not work in an environment filled with potential WTF around them?

     

    /me raises hand...   sheepishly.... 

     

    You aren't looking hard enough...

     

    Captcha:  Quality 

  • (cs) in reply to David
    Anonymous:

    It's actually not that bad (it is legal XML, after all).

    Uhm its parsable XML, but it is not legal XML.

    And yeah its pretty bad.

    The only point to the XML is to define the "fields" (and map them to something) But what "fields" are you defining?

    As far as I can tell, they've tied the fields to the ORDER the fields tags are listed (that is the first field tag is the first column in the csv data, etc). And that defeats the purpose of using XML.

     

  • (cs) in reply to Tim
    Anonymous:

    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.

    How does that solve anything? Are you saying I'm not allowed to have tabs in my fields?

  • enterprisey! (unregistered) in reply to Ishai Sagi
    Anonymous:

    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!

    the story isn't complete. did you actually use xpath in your application? i hope so.

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

Log In or post as a guest

Replying to comment #103112:

« Return to Article