To XML or not to XML?

[Xizor]

Ok, it has been a while since I've needed to make an involved web page. Coming back on the scene now is a bit confusing, what with all the cool stuff to use like XML, PHP, MySQL, etc...

So here is my question. I'm in search of a good dynamic way to generate web pages which separates content from presentation. I am seeking to create a web site that, to put it succinctly, has a list of users and sets of information corresponding to each user.

I am familiar with how to do this using PHP, MySQL, and regular old HTML. I maintain the user database in MySQL and dynamically present it and the information with PHP. This is very easy to do in terms of coding for it.

But I'm wondering? Is it time for me to switch to the XML with XSL method instead? 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. And I shouldn't have to write a parser, there should be standardized ones for certain purposes. But wait, isn't that what HTML already is? A bunch of <dog>Spot</dog> (figuratively speaking) with the parsers having been written and mostly standardized between companies ages ago? XML to me is just someone saying, "Uh, take HTML, but you can make your own tags, and instead of calling it HTML, we'll call it XML?" Big deal. Unless everyone adopts XML and makes it a truly common way of storing data separate from presentation, then XML is a moot point. This isn't anything new though, various groups have been trying to get various methods of formatting data standardized forever.

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

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), 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. But then again, if you just make the MySQL data available in a raw format, then you've got XML in a sense.

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 Schaffert]

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.

 

[AURIA NEWS]

I am familiar with how to do this using PHP, MySQL, and regular old HTML. I maintain the user database in MySQL and dynamically present it and the information with PHP. This is very easy to do in terms of coding for it.

Yes, JSP, PHP, ASP or whatever and database is sufficient for most purposes. XSL is one option but not necessarily an easy one/or give you any benefit when separating content from presentation when using database as data source.

But I'm wondering? Is it time for me to switch to the XML with XSL method instead? 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. And I shouldn't have to write a parser, there should be standardized ones for certain purposes. But wait, isn't that what HTML already is? A bunch of <dog>Spot</dog> (figuratively speaking) with the parsers having been written and mostly standardized between companies ages ago? XML to me is just someone saying, "Uh, take HTML, but you can make your own tags, and instead of calling it HTML, we'll call it XML?" Big deal. Unless everyone adopts XML and makes it a truly common way of storing data separate from presentation, then XML is a moot point. This isn't anything new though, various groups have been trying to get various methods of formatting data standardized forever.

XML however, is here to stay, if you import RSS feeds (blogs, news etc.) or some other messages that are in XML format, you can't ignore XML. I guess you can plug in PHP RSS parsing class for handling these BUT learning XSL can be an option too.

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

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), 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. But then again, if you just make the MySQL data available in a raw format, then you've got XML in a sense.

Server side is still the way to go in web development, with some XML processing or without it. But XML as "file format for creating file formats" given the increasing number of tools (like XSLT, XQUERY, different parsers etc.) is very handy for almost any kind of software development these days.

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.

But in the end, the final outcome is what matters, not the technology used. Good luck, Toni Uusitalo

 

[Bob Foster]

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.

The things first-year undergraduates write are not XML parsers.

Writing an XML parser is difficult.

Bob Foster

 

[Toni Uusitalo]

Hey, check the
Subject: round two: XML vs DBMS
thread (21.7), forget the outputs of my banana brain!

 

[Peter C. Chapin]

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.

Although this is a gross simplification one rule of thumb that I think works pretty well is this: if your only interest is presenting information to humans who are using web browsers, then HTML is perfectly satisfactory (using PHP, etc to generate it). However, if the audience of your information includes other programs, then encoding the information in HTML is awkward because typical HTML documents (created for human consumption) do not describe the data precisely enough.

Referring to your example: suppose you wrote documents with XML that included your own <dog></dog> elements. Now suppose you later wanted to write a program that created, say, an index of dog breeds mentioned in your documents. It would be an easy task.

<para>The <dog>mastif</dog> is a large dog. The <dog>terrier</dog> is a smaller dog.</para>

You could get a similar effect with HTML by making heavy use of <span>

<p>The <span class="dog">mastif</span> is a large dog. The <span class="dog">terrier</span> is a small dog.</p>

The problem with this is that you can't enforce any rules on how the various classes interact. You can't create a schema for your "pseudo- elements". Consequently applications that need to process such documents would have to do more work to check for their consistency. With XML a validating parser can verify that at least the schema is obeyed, leaving your application to check only the higher level issues and apply the proper semantics to the elements you defined.

Peter

 

[Marc Mickey.]

Sometimes i have the feeling that dev people are kind of lemmings ( do y remember this game?) that use to follow what Microsoft or other major companies say. I'm very worry about this.

1/ Xml is useful to translate into several language a whole site. Your translator can quickly translate sentences between tags. 2/ It's a good solution if you're data will be read by several different softwares (flash, c#, java, whatever) 3/ it's easy to use because it's a simple file.

Nevertheless, there are several programming layer before manipulating datas. This is the only problem. You have to learn a lot to use xml . Don't think about xslt. This is not an interesting thing. If we use in dreamweaver, coldfusion or php , to build dynamic pages you don't need xslt. It's good if you're data are organized by levels and sub levels. For instance, you create a jazz members' association file. first level , name, surname, etc. but one entry, is a door to another field lists. this entry will be musician informations with : bio-discography etc.... Comparing to sql, xml can organized different datas which should be recorded in different databases.

 

[Toni Uusitalo]

Sometimes i have the feeling that dev people are kind of lemmings ( do y remember this game?) that use to follow what Microsoft or other major companies say. I'm very worry about this.

The Game is older than The Game Lemmings ; The Tyrant rises into power by the help of banana brain lemmings, then open data format (XML) comes into rescue and the proletariat gets its revenge - the tyrant looses his head. The world is filled with dance and joy for a while... until new tyrant rises... and so on

Seriously, one of the promises of XML has been than "open data format" that can be processed after MS word etc. has mysteriously been forgotten (within 10 years?!) and nobody remembers MS anomore! This is kind of nice goal, this "archive safe" data format, although sometimes it seems like the motion is more important than the actual goal with all these "XML recommendations".

1/ Xml is useful to translate into several language a whole site. Your translator can quickly translate sentences between tags. 2/ It's a good solution if you're data will be read by several different softwares (flash, c#, java, whatever)

Yes, that's very true. If you must do translations or versions for different clients, XML format is very good choice

3/ it's easy to use because it's a simple file.
Nevertheless, there are several programming layer before manipulating datas. This is the only problem. You have to learn a lot to use xml . Don't think about xslt. This is not an interesting thing. If we use in dreamweaver, coldfusion or php , to build dynamic pages you don't need

xslt.

True. If one knows his/her SQL and server side programming layer (JSP,PHP etc.), it might be good to stick with those.

It's good if you're data are organized by levels and sub levels. For instance, you create a jazz members' association file. first level , name, surname, etc. but one entry, is a door to another field lists. this entry will be musician informations with : bio-discography etc.... Comparing to sql, xml can organized different datas which should be recorded in different databases.

I'd say that database is the best tool for saving data, hierarchical or not. We'll see if increasing database/XML integration or native XML databases will REALLY help us lemmings someday or just make us more confused .

sorry about my evil english

Toni Uusitalo

 

[Sebastian Schaffert]

The things first-year undergraduates write are not XML parsers.

Writing an XML parser is difficult.

If you restrict yourself to a "minimal XML" first, and leave out things like attributes, processing instructions, namespaces and entities, it is pretty straightforward, you even don't need to know much about parsing theory.

All you need is a very simple lexer (two states: element parsing, data parsing). If you in addition want to check well-formedness, you'll need a stack also, but that is optional. Adding attributes and namespaces is also not that difficult.

 

[Peter Chong]

XML is standard data module vs. DB is vendor specific data module. You could try MS Access DB(most popular) into XML/XSL try xmlwizard from www.exmlsoft.com

"Xizor" wrote:

Ok, it has been a while since I've needed to make an involved web page. Coming back on the scene now is a bit confusing, what with all the cool stuff to use like XML, PHP, MySQL, etc...

So here is my question. I'm in search of a good dynamic way to generate web pages which separates content from presentation. I am seeking to create a web site that, to put it succinctly, has a list of users and sets of information corresponding to each user.

I am familiar with how to do this using PHP, MySQL, and regular old HTML. I maintain the user database in MySQL and dynamically present it and the information with PHP. This is very easy to do in terms of coding for it.
...

 

[Bob Foster]

If you restrict yourself to a "minimal XML" first, and leave out things like attributes, processing instructions, namespaces and entities, it is pretty straightforward, you even don't need to know much about parsing theory.

All you need is a very simple lexer (two states: element parsing, data parsing). If you in addition want to check well-formedness, you'll need a stack also, but that is optional. Adding attributes and namespaces is also not that difficult.

Yes, but there is no such thing as "minimal XML". There is only XML and not-XML. Things that parse not-XML are not XML parsers. (Or maybe they are not-XML parsers. ;-)

I understand what you are saying and I am sure undergraduates can be taught to write a parser for something loosely approximating XML, but they should also be taught that XML has a rather strict definition of what a parser must do in order to call itself an "XML parser". That's all I'm saying.

Bob Foster