Ok. I'll bite and take a stab at this. We use XML to send our customers large amounts of data to integrate into their applications. Your example is very simplistic. What if you have nested elements? Three, four (or more) levels deep? Do you really want to hand your customer some proprietary scheme for how to parse your syntax so they can import your data? Or would you rather hand them a DTD and let them use off the shelf parsers and editors?
Also, what about validation? We can run the XML our application spits out against the DTD and validate it for any errors before sending it to the customer. You're right, if your data is only meant for your own consumption. If you have to make other people eat it however, I think that is where a standard like XML fits. Jason > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Richard O. Hammer > Sent: Wednesday, March 26, 2003 3:34 PM > To: [EMAIL PROTECTED] > Subject: Re: [Juglist] What good is XML? > > > In this example, consider three possible representations of the data. > > 1) Natural language: > > Mike bought a book "Professional XML Databases " written by Kevin > Williams et al from amazon.com. > > 2) A language designed as needed for a specific application. In this > case a set of lines of text with headers separated by colons. And > probably there is further specification of allowable headers and bodies. > > Book: Professional XML Databases > Author: Kevin Williams et al > Buyer: Mike > Seller: amazon.com > > 3) XML > > <?xml version="1.0"?> > <book=" Professional XML Databases" Author="Kevin Williams et al" > Buyer="Mike" Seller="amazon.com"> > > The question I raise is not whether a program can understand natural > language, #1. The question, rather, is whether a program can > understand #2, a textual language following a specific syntax. > > And clearly, it is not hard to write a program to read #2. There are > utilities available to read data arranged like this, perhaps more > readily available than XML parsers. > > So which is better, #2 or #3? > > I find #2 easier to read. I think it is much better. I still have > not seen reason to use #3 where #2 can be used. > > Rich > > > > Daniel Zhang wrote: > > The main reason that we use XML-structured data is because > > programs/applications lack of human beings' intelligence to > > process/retrieve usefull > > information from the incoming data, say, raw data in plain English. > > Therefore we have to use a sort of protocol the computer recognize for > > that purpose. > > XML is the fashionable protocol/structure right now to do that. For > > example, a chunk of streamlined data says: > > > > Mike bought a book "Professional XML Databases " written by Kevin > > Williams et al from amazon.com. > > > > In one's mind, he can quickly pull out information and structured like: > > > > Book: Professional XML Databases > > Author: Kevin Williams et al > > Buyer: Mike > > Seller: amazon.com > > ... > > > > But for system application, it cannot analyze and categorize such a > > simple data in a way we do. You have to "sandwich" and group these data > > like > > XML for it to understand. It is particularly effective when you have > > much more complicated data. > > > _______________________________________________ > Juglist mailing list > [EMAIL PROTECTED] > http://trijug.org/mailman/listinfo/juglist_trijug.org > > _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
