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

Reply via email to