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

Re: Re: Re: XML for databases?!?! Is it just me or is the rest of the world nutz?

by dsheroh (Parson)
on May 24, 2002 at 13:53 UTC ( #169064=note: print w/ replies, xml ) Need Help??


in reply to Re: Re: XML for databases?!?! Is it just me or is the rest of the world nutz?
in thread XML for databases?!?! Is it just me or is the rest of the world nutz?

XML doesn't validate itself either. It requires the use of external software to validate it. So, if you're concerned about the integrity of your database and you receive CSV data, you could just as easily write external software to validate that as well.

(If you reply with something along the lines of "But it's easier to write a DTD and feed it through a generic validator than it is to roll your own CSV validator", please provide concrete evidence to back this up. Based on the few examples I've seen, DTDs seem to be a programming language unto themselves, no less complex (and far more verbose) than the level of perl code that would be required for this task.)


Comment on Re: Re: Re: XML for databases?!?! Is it just me or is the rest of the world nutz?
Re: Re: Re: Re: XML for databases?!?! Is it just me or is the rest of the world nutz?
by mirod (Canon) on May 24, 2002 at 15:06 UTC
    you could just as easily write external software to validate that CVS as well

    Not quite. First if you are dealing with sloppy providers they might not include the CVS headers and then how are you going to know which field is missing when that happens?

    Then really, DTDs are written using a language designed for language description. You can't really compare it with a programing language, more with the table description part of SQL, or with lex+yacc. For a concrete evidence You can have a look at the IEEE Standards DTD (be warned though, loading the DTD crashes my Mozilla) and tell me how easy it would be to write a Perl program that would parse and validate data tagged according to that DTD (it's SGML, but XML is just the same). I know I'd rather write the DTD and let any parser do the job!

Re^4: XML for databases?!?! Is it just me or is the rest of the world nutz?
by Aristotle (Chancellor) on May 24, 2002 at 15:08 UTC
    esper++, my thoughts. You know how it is with function prototypes.. there comes a point where the compiler simply can't be clever enough to check the validity of arguments and you have to check at runtime. XML vs CSV is similar.

    Makeshifts last the longest.

Re: Re: Re: Re: XML for databases?!?! Is it just me or is the rest of the world nutz?
by Stegalex (Chaplain) on May 24, 2002 at 15:22 UTC
    Did you actually think that I was suggesting that XML validates itself? I use XML::LibXML to do that. One method call, validate(). Sure looks easier than writing your own edits for CSV's. Face it, I am right. You are wrong.

    ~~~~~~~~~~~~~~~
    I like chicken.
      One method call, validate().

      And what, in the absence of a DTD, is the XML validated against? Simply that the brackets are all matched and it's syntactically valid? That's the same level of "validation" that you get by counting the commas in each row of a CSV file. Neither one tells you whether the data is formatted appropriately for your intended use.

        By all means, if you are more at ease with CSV use CSV. It might be really well-suited to what you are doing and you might not need anything else. I will also be the first to admit that XML is no silver bullet. If people want to throw garbage at you they can throw XML garbage just as well as they would send you useless CSV.

        OTOH in the real world XML takes care of encodings (ever received UTF-8 data when you were expecting "regular" latin1?), most people feel that it is more self-documented than CSV. It is also more flexible: it can model more than just tabular data and it is relatively easy to write XML code that can survive moderate changes in the input format (such as new element types being added) without upgrading. The tools are also pretty good, at least on par with the tools you can find for CSV.

        In short there is really no need to change all of your tools and all of your processes just to become buzzword-compliant. I don't think any one is advocating this BTW. So stick to CSV if you want to.

        I just want to point out that there is really no need to try to convince people that CSV is better than XML. XML is just a rather powerful and well thought-out low-level standard for documents and data interchange. I hope you don't spend your days writing low-level CSV code and that the main logic of your applications is a little bit more interesting ;--) So really whether the underlying format of the data is CSV or XML is not that important. Choose the one you are comfortable with, provided it's powerful enough to work now and in the future.

        You know, I rather like ASCII myself, but I don't really try to convince people who use Unicode that they stuff is useless, and I must admit that sometimes 8 bits just don't cut it and I use Unicode.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (10)
As of 2014-11-26 09:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (165 votes), past polls