the other side of the coin is validation, schema, etc. consider required vs optional fields, datatype and all that good stuff, especially standardized as well. it's not just content.
0.02 -----Original Message----- From: Wesley(Xiaoyu) Zhang (xyzhang) [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 1:20 PM To: [EMAIL PROTECTED] Subject: RE: [Juglist] What good is XML? #2 is better than #3 if only human readability is concerned. However, #3 is superior to #2 in terms of seperating meta data with content itself. In #2, a way is needed to identify Book: is not part of content. In #3, it's easy to know "professional XML databases" is the only content of book tag. EDI is using a similar approach to #2 to deliver the documents. Now ebXML is considering using XML to describe a EDI document. The main reason ebXML is doing so is that #2 approach is just not as flexible as #3 approach to describe the data. $0.02 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 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 _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
