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.

 

[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