Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re: Re: Re (tilly) 2: Why is Perl so bad with XML?

by Anonymous Monk
on Feb 01, 2002 at 06:29 UTC ( #142617=note: print w/replies, xml ) Need Help??


in reply to Re: Re (tilly) 2: Why is Perl so bad with XML?
in thread Why is Perl so bad with XML?

but one day your customer will have to send thier data to an MS shop, and they'll ask for XML, and then they'll ask you if they can send you their XML, because that's easier for them. It's just how the world works - we can't stop it turning even if we want to.

I'm not in the industry myself, so I have no own experience with this. But your statement has a touch of self-fulfillment. If everyone thinks everyone else uses it, everyone will start to use it.

Or is it de facto so that the majority out there uses and requires XML?
  • Comment on Re: Re: Re (tilly) 2: Why is Perl so bad with XML?

Replies are listed 'Best First'.
Re: Re: Re: Re (tilly) 2: Why is Perl so bad with XML?
by mirod (Canon) on Feb 01, 2002 at 07:30 UTC

    You'll have to admit that XML is a very good exchange standard: it allows you to specify the encoding of information, it get rid of line ending problems, it is reasonably sef-documented and quite human legible. If all else fails you can always fire up vi and figure out what's in the file you just received.

    I know CSV is somewhat self documented if you include column headers but it is still easier to have the name of the field right around the field, even in the middle of 2 Mb of data than to have to go back to the beginning of the file, read the headers and figure out in which column you are. Plus some CSV files are pretty ugly. I just had to process the export of an Access DB that included multi-line fields that was a real pain to parse: there was no special end of record marker so Text::CSV_XS could not read records properly. An XML export would have solved this problem.

    Plus of course the hype factor makes it way kewler for management to say they're sending XML than CSV. Maybe tilly should start a W3C working group on CSV ;--)

      Did you try using DBD::CSV or Text::xSV to pull data from the Access CSV dump? (Which I assume was dumped using Microsoft's standard save as CSV.) Anyways nobody keeps data in that format for working, if it is tabular data then it is destined for life in a relational database where it is far more easily manipulated than it is in CSV. (Unless it is going to a financial analyst in which case it is destined for life in an Excel spreadsheet.)

      As for W3C, why waste my time? I don't think that CSV is an appropriate solution for their problems. It is a good one for interchanging a lot of the data that exists within the bond world, which is why there are standard formats there which have been used for years specifying CSV formatted data. They are here. They work. People use them.

      And when it comes to management and hype, sometimes that is life. Personally I prefer it when developers are free to choose the most cost-effective tools for what they are doing. (For one thing PHB heavy companies don't do so well. And companies that always seek to follow the herd tend to find a lot of nasty cliffs. Big companies have enough intertia to survive most such cliffs, small ones do not. Either way, they aren't fun for the developers who go over them.) If that means XML, that means XML. If it means CSV, then that means CSV.

      When it comes to tabular data I prefer CSV for several reasons. The first is that it is easier to see that it is tabular data at a glance. The second is that I prefer getting a 2 MB file to a 10 MB file. The third is that it takes a lot less work to set up a CSV format than it does to set up a DTD, etc. The fourth is that most people who work with tabular data already have more tools for CSV than XML. (Try any spreadsheet application.)

      For non-tabular data, well CSV is not appropriate for that. Use the right tool for the job. As for when XML makes sense for that, I don't have much of an opinion. I haven't had to solve that problem extensively. Certainly it was originally designed for that problem space, and the sheer effort that has gone into XML undoubtably has resulted in some effective tools for some problems. The hype has also definitely resulted in it being used for problems where it doesn't make sense. I just don't know where the boundaries are.

      You'll have to admit that XML is a very good exchange standard: it allows you to specify the encoding of information, it get rid of line ending problems, it is reasonably sef-documented and quite human legible. If all else fails you can always fire up vi and figure out what's in the file you just received.

      I quite agree. I'm no standards expert, but I think one of the clearest benefits of XML lies in a field wider than just code. With more and more dynamic community-based sites popping up by the day, and you average Joe wanting to make the stuff he writes on them look cool, the general public is becoming much more familiar with HTML. And, "XML looks just like HTML".

      The angle brackets of HTML looked very odd to me when I first saw them, and I'm sure they still do to anyone new to that stuff. But as the new generation takes up computers, HTML will begin to be understood by people, and I think eventually XML or a derivative of it will become the language for all code-related human-maintained files. By this, I mean that configuration files for your Perl programs will probably be written in XML, as that way everyone will understand them. None of all this silly var: value syntax that has to be relearned for every program that works slightly differently. Feel free to disagree, but I think that's a good thing. (/me shudders when he thinks of Esperanto, and hopes the same doesn't apply here...)

      I speak not as a devotee of XML; I'm still deciding on my module of choice, my familiarity with XML::Parser amounts to a brief look over the tutorial here, and reading the standard gave me a brain-ache. I certainly don't force people into using it. But I am excited about getting an oppurtunity to use it. I admit, tilly, that none have come up yet, but if/when one does I'll jump at the chance.



      --
      my one true love
      Actually, I was not even making a remark on how XML is. I was just wondering about your opinion -- if it's backed up by reality or if it's just an attitude.
Re: Re: Re: Re (tilly) 2: Why is Perl so bad with XML?
by Matts (Deacon) on Feb 01, 2002 at 12:25 UTC
    Remember that XML is a de jure standard, not a de facto one (well, we can pick nits about whether a "recommendation" from the W3C is a "standard" or not, but most Corps see it that way, and there are plans afoot to put XML through the ISO). That's very important to PHBs. And if you prefer de facto standards, well there's always MS Excel ;-)

    But yes, if everyone thinks everyone else uses it, everyone does start to use it. That's what happened with Java - Sun spent billions (yes, literally) of dollars selling it via articles and advertising and so on, and they convinced the world that it was the next big thing, and lo and behold, it was the next big thing. The beauty of XML is that everyone else is spending billions promoting it, yet we as Perl hackers get to play in the same ballpark as the MegaCorps, which is nice for a change.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://142617]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (6)
As of 2018-12-14 21:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How many stories does it take before you've heard them all?







    Results (69 votes). Check out past polls.

    Notices?