Altova Mailing List Archives


Re: To XML or not to XML?

From: Sebastian Schaffert <wastl@-----.--->
To: NULL
Date: 7/25/2003 2:58:00 PM
Xizor wrote:

[...]

> But I'm wondering? Is it time for me to switch to the XML with XSL method
> instead? 

Yes and no. No: PHP, although not exactly a very nice language, is still
much more convenient than programming in XSLT. Yes, well see below.

> Everyone seems to be talking of XML as the end all be all. I've
> looked into it, and on the surface, I just can't tell if it's worth it. I
> don't really see the benefit. XML is just a "create your own HTML tags"
> and then figure out wtf to do with them orgy. Great, so I can write
> <dog>Spot</dog>. Whoop de do, that's useless to me unless I write a parser
> for it to display it in a user friendly way. 

For several reasons it is not at all useless:
1. In your example, you already mention a very good point, although you 
   maybe didn't recognize it. What you did is to use a tag <dog> to describe
   a dog. In HTML, you would have used something like <i> or maybe <span>". 
   A properly designed XML document can be much more descriptive, and even
   make the content machine understandable (the machine just needs to know
   that dogs are enclosed in <dog> tags)
2. XML is a plain text format which can be read by any editor, while MySQL
   is a "proprietary" (not exactly since it is Open Source) binary format.
3. XML is standardized, which allows for better interoperability between
   different programs.

> And what about support? All the browsers still have to make their own
> parsers of XML and XSL.

No. Existing parsers can be used, there are many available for free. In
addition, writing an XML parser is not at all difficult, it can easily be
done by first-year undergraduates.

> 
> As far as I see it, XML is no different than any other data format in
> purpose. It's a standard way of storing data, just like a JPEG is a
> standard way of compressing images. The only difference I see that is
> worth anything, is that XML focuses on bringing the data to the client
> side, then doing stuff with it there (let's say through JavaScript),

No. The main issue is that XML allows to "annotate" or "mark up" parts of
the data and hence provide it some kind of (application specific) meaning. 

But XML is essentially merely a syntax to do this. Other formalisms could do
as well, like Lisp S-expressions. The main advantage is that XML is
standardized, easy to parse and accepted by most developers.

> whereas a typical system using a combo like PHP and MySQL processes the
> data on the server side then sends the result to the client. 

XSL transformations can be evaluated on the server side in the same manner.
The Cocoon project provides a framework for this, for instance.

> But then again, if you just make the MySQL data available in a raw format,
> then you've got XML in a sense.

No, you haven't. XML is *semi*structured, while data in a relational
database is *fully* structured (ever tried to store an annotated text in a
relational database?). In XML, you don't have "NULL" values for example,
what does not exist is simply not there.

> 
> I'm just confused. At the end of the day, I just want to know where the
> reality is, where the practical solution is, to having a database and
> showing your average web surfer the data they want in the way they want to
> see it, all within a pretty and easily modified (stylistically) web page.

-- 
Sebastian

PGP Key fingerprint =  
       13 1D 2E 4F 20 3E C9 1F  4C 57 52 87 8A 80 48 4D  F5 E9 97 EC 

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.