Benefits Of XML...

Just wondering, can anyone explain to me the major benefits of what XML has...


I have read quite a large bit about it...

My understanding is that you use say PHP to extract the data via MySQL.
Then structure it using XML and format the output using HTML or XLS (Stylesheet?)...


Is that correctus?

I recommend you to find some already written topic here or anything else. I think time for such topics already gone :-(.

Is it? really?

I"ve been trying to work this out my self.
Honestly I haven't found a legitimit usage of XML IF I already have a Database backend running the show.
It would seem to me that in this type of situation the usage of XML is very redundent...
But XML is supposed to be used as such like a protocol between the database and the html...
But why?
Whats the point, I can format my output faster, and easier than I would if I tried to use an XLS style sheet. With little or no over head on my part...
So really what is the point of using XML....

mikkri,
I'm curious to hear your responce, after all your are a consultant...

Hello,

My original post was about comparision RDBMS vs. XML storage.

But we can discuss a bit different approach. Assume I have a database and XSLT-based web-site (there XML to HTML transformation is used). When I want to show some data from database simplest way is to embed it into page xml file and only then execute XSLT transformation. This is much simpler than changing results of transformation.

Most noticable advantage of such solution is that site's design may be vary flexible. For example, you can use a bit different design template during weekend. Or you can allow your registered users to select one from the defined list. Another option is when you have e-mall there each customer want to have its personal web-shop. So you are using one engine to run all shops, but provide very customizable design templates. Such server may provide very cheap services for e-commerce novices.

Most noticable disadvantage of such solution is that XSLT transformations is usually very time consuming. So you need to use caching solutions or very expansive hardware. But in case with frequently updated data in database you can't cache pages, so you are forced to buy expansive hardware or limit number of simultoneous visitors. Both are not great.

Hope my opinion is now clear :-). What do you think? What is your experience?

So, With XML, you have data that can be refreshed without having to refresh all the images, HTML and looks of the site is that it?


Is XML where you have a database of records, can refresh those records or add, edit, delete records while still on the original page without the HTML having to refresh???

Please coloborate a little...

Zane

XML is just a standard format for storing information. XML itself doesn't "do" anything - only the functions in programming languages can "do" things with XML. XML simply says "all documents that store information will be in this format and follow these guidelines." That's all XML is.

Anything you have heard where XML "does" something is based on a technology built on top of the XML standard, i.e. something that works with and manipulates XML documents.

Anytime you have heard of an XML "database", it simply means a database where the information is stored in the XML format.

The major benefit of XML is that it provides a standard format that all information can be stored in. These means that if I export some sort of data from my script, another script that recognizes XML will be able to work with it.

In the past, most applications exported data in their own native formats, and in order for another application to work with the data, it would have to have some sort of converter to read the native format of that application. XML solves this problem.

Even if you don't plan on having other applications use your data, XML provides a format that is already designed that you are able to use when storing information. Rather than designing your own file formats as well as functions to read and manipulate them, you can just store the data in XML format.

Other concepts based on XML include servers that communicate using XML-based packets. As more and more functionality is built into programming languages to manipulate XML documents, less time can be spent on writing code to manipulate the data.

I thought xml was made to be a transitional language, easy to gauge back and forth between various other data formats and databases...

JeffCT placed too good comments that explain XML technology basics.
Also web-services are coming and they are based on XML documents interexchange. Keep it in mind.
Anyway to study XML basics is better to find some good toturial and then discuss your thoughs.

1) You may use XML to split presentation layer and business logic/data access layers. I've provided example of such separation.

2) My example used server-side XML processing, so when compared to standard JSP pages there is no difference from client-side view. But there is emerging standards such as XForms that define rules for client-side XML processing. With XForms you may send and receive XML data while staying in the same page. Also Macromedia Flash is now going along the same direction - load presentation code once and exchange with server many times. Oh! I used to develop Java applets that interact with server via XML-RPC without reloading page. My conclusing is that world is now going to be more close to rich-clients than thin-clients. And XML is only one of powers for this movement.

Three basic reasons I've used xml/xslt rather than querying a rdb in certain instances - even when the data will only be used within one website.

1. Repeated views of the same data (or subsets thereof)

3. Naturally Hierarchical data

2. A legacy database that is poorly organized and indexed for the queries I'm running against it.


Specifically, I've used xml to store the structure of a catalog in an asp application object. I then use xslt to display a top-level overview of the catalog on the home page, and simple traversing of the hierarchical xml for drilling down through catagories in the catalog.

1. Harddrive access is HD access, from a file or from rdb.
2. rdb's were designed to repalce Hierarchical databases in the 80's. Hierarchical databases were a nightmare back then, and still are today. I really don't see this as an enchancement to rdbs...
3. So you want to export the data to a format that doesn't support indexs? A better solution would be to have a DBA assist you to increase the rdb proformance by applying the needed indexes. Atlernately you could create a new table that contained your query results, hence increasing proformance by cashing query results...

1. a. client-side caching (actually, I haven't tried this because of concerns of support, but in theory it should work.)
b. I typically store the xml and xslt as FreeThreadedDomDocuments in the application object so the only HD access should be at application startup.

2. Although I agree that RDBs are much better for relational data, I'm curious what the advantage is with naturally hierarchical data. Far from creating a nightmare, I consider xml/xslt development much easier conceptually than converting rows and columns into parents, children and the data associated with them.

3. The particular example I'm thinking of is part of a proprietary system that clients have only very limited control over the structure of. It was designed to achieve it's initial purpose - which is not my purpose - but it contains the data I need, and is regularly updated. I could simply create a copy of the relevant data in a new database with a structure and with indexes more appropriate to my specific needs - indeed I have done that in the cases of some relational data. When dealing with hierarchical data however, I choose a hierarchical structure.


[DUMB NOTE: I've been accused in the recent past on another forum of defending myself too combatively. Perhaps I'm developing a tone problem in my not-quite-middle age as that is not my intention. We disagree, and I would like to point out why. If you find fault with my reasoning, I really do want to hear and learn from our disagreement]