Re: PHP and XML?

Shashank Tripathi wrote: > The idea for this discussion is NOT to flame anyone, I know this is a > digression already from PHP, but I need to know the "big deal" about XML > because PHP is touted as being weak in that area. So I'll calmly wade > through your points. Who touted that PHP was weak in the XML area? As far as I can tell it's fairly strong, and getting stronger. > | Actually, a purchase order is a good example of where XML is much better > | than a CSV or flat file. How do you show the information about a > | customer and then 'n' number of products that they want to purchase? > Why not? First, lets say the delimiter is "{|}" and not a comma, or any > other character that I am SURE doesnt occur in my data. Well, in XML you don't have be sure that comma or whatever doesn't appear in the data. > Then I define two > flat files. But I wanted one file. Now I have to manage two files and make sure that they both get to where I want to send *and* to make sure that the receive knows that they are related and form a single order. > Cant my application take care of the data then? yes, but it's more a question of ease of use. > | XML is suited to representing info that can be placed in a tree, with > CSV > | only really useful for table based data. (i.e. data that can be placed > | in a table.) > > This is getting interesting. Why? Isnt the above information representable > in a tree? I mean a Purchase Order, for example, can be well represented by a tree with a header part and order part. The header hold info about the order, buyer etc, while the order part holds the list of items to order. <art type="ASCII"> root -+- header -+- buyer name | `- buyer address `- order -+- item +- item `- item etc </art> A CSV file can represent the Order Items quite easily because they easily fit into a table. Once the structure of the data gets more complex, i.e. an order with buyer info as opposed to just a list of items, CSV files can't do it, and peope would have to resort to hacks like using two separate files like what you did above. A tree structure can handle this data. XML files basically represent trees. > | Then you've also got the problems with CSV like how do you represent > | different character sets, how do you represent a comma value in CSV. XML > | provides uniform solutions to these problems. > Character sets are BARELY the problem! The delimiter I showed you above > NEVER appears in CHinese (2 different charsets), Japanese, Vietnamese, The charset problem is not to do with delimiters, it's got to do with what happens when someone wants to send data that can not be represented in plain ASCII. The start of an XML document is tagged with what charset is being used for the data. > | As for complexity, XML parsers shield application programmers from > | having to directly deal with the XML syntax. > > We can do the same with the delimited files as well, no? Cant I write a > simple VB app, or even a web-based PHP app to read/add/modify info in the > right places? As for adding information to the DTD being convenient, yes you > can add it to the DTD. But then you have to update the actual data isnt > it Depends, if you add an optional tag to the DTD, then no you *don't* have to go update your data files they will still work. > | I strongly recommend buying a good book on XML and reading it from start > | to finish. I can recommend "XML by Example" from QUE. > > I have the WROX book, and thats much more respectable than the "XML by E" > (in my humble opinion). But most of these books do not add anything to my > plate that I already cannot find on the net. Well I've read reviews of "XML by E" that either praised it or flamed it. It is an introduction and it suited what I was looking for at the time. From here on in I'll probably look for stuff on the net for more detail. Anyway, I'm happy. ;-) > | XML and most of it is not obvious if you just give it a quick glance. I > | was surprised. > Would you like to share WHAT surprised you? Features like being able to validate complex docs against a DTD. Being able to extent DTDs without having hose any previous data. Name spaces and being able to mix tags from other DTDs together in the same document. Also other techniques for formatting and processing XML that are just not practical with CSV. > You *might* be surprised if you > spend sometime thinking about delimited files as well. I doubt it. ;-> > Will look forward to your comments/experiences..thanks! I am not being > cynical, just playing the devil's advocate here. For very simple things like a table of data, CSV is simple and easy. The problem is when you want to represent data with more complex structures and also exchange them with other people, and also be able to extend the kind of data that certain document type can hold. CSV are fine when you have full and absolute control from start to finish, but the networked world is just not like that. -- Simon Edwards Animated Design, Melbourne http://www.animated.net.au/ Ph: (03) 98850990