Q for Dmitry Kirsanov : XSLT's value

[Dave Knipp]

Dmitry,

I was curious what your take on when to use XSLT over any other presentation technology within J2EE.

In my opinion, XSLT's most powerful element is that it requires no code to extract and transform data from an xml document. So it would seem that XSLT could be very valuable within an enterprise setting since it would save the processing of using SAX or DOM within java and would cater towards many company's who already use XML to transfer data.

But, why would you use XSLT to display your data within a typical web application? Do you go through the extra step of creating an xml document out of raw data from a database just to use xslt for your presentation?

I've seen many company's who do this and would be interested to hear what your experiences are as well. Why would you go through the trouble of building an xml document from the raw data in your database if you are only going to use that xml document in association with xslt? Are there any advantages to doing it that way other than having your data in an xml format?

Looking forward to checking out your book!

Thanks,
Dave

[Dmitry Kirsanov]

> But, why would you use XSLT to display your data within a typical web
> application? Do you go through the extra step of creating an xml document
> out of raw data from a database just to use xslt for your presentation?

Very good question, thanks!

No offence, but it seems to me that this question shows your programmer's bias As a programmer, you see the problems that come with retrieving and processing data, but fail to see the problems associated with presenting that data. In other words, once your business logic has successfully finished, you consider the task fulfilled and the rest trivial, right? Not even close.

As a designer, I have another perspective on the whole story. From my viewpoint (of course I'm now exaggerating for the sake of the argument), it's the programming logic that is the easy part. Just run a database query and do some calculations - that's pretty straightforward. But then comes the really difficult part: we need to show the output data to the user in the most unambigous, logical, consistent, and helpful way. There's a lot to it, but the most important prerequisite is that the data I (as a designer) am working with is itself unambiguous, logical, and consistent.

And this is where XML enters the play. XML is, basically, a formalism for consistenly naming things; you see some entity, you tag it with a name that fits it. (Usually, in the process of such naming you also discover lots of problems with the consistency and logic of your data.)

Now the importance of XML in web development should be obvious: It is a common language that lets programmers send their data to designers, without each stepping on the other's toes. You (the programmer) are relieved of thinking about <td>s and <tr>s and spacers and images; you just give me your data and explain (using XML) what part of it is meant to be what. I (the designer) an relieved of thinking about how or where from this data came to be; I just take it and transform it into a presentation. Apart from being a language of communication, XML can also serve as a checkpoint which lets you make sure that the data you produce makes sense, and which lets me make sure that my transformation and presentation algorithms are indeed a good match for this data.

So, to put it simply, XML is the best way to keep sanity and maintainability of any reasonably complex information processing system, and a web application is certainly one of the model showcases for XML and XSLT. It may seem unnecessary at first, but if you actually try it you'll realize how much more elegant and modular the system becomes - and how many problems it had before

I also want to add that the programmer's viewpoint on web development is absolutely dominant in books and online writings on this topic, while a designer's perspective has much smaller presence, and an integral view that recognizes the importance of both parts of the equation and the role of XML connecting them is even rarer. This was one of the main motivations for writing my book.

[Gian Franco]

Hi,

I'm not sure I understand the following:

Now the importance of XML in web development should
be obvious: It is a common language that lets program-
mers send their data to designers, without each step-
ping on the other's toes. You (the programmer) are
relieved of thinking about <td>s and <tr>s and spacers
and images; you just give me your data and explain
(using XML) what part of it is meant to be what. I (the
designer) an relieved of thinking about how or where
from this data came to be; I just take it and transform
it into a presentation. Apart from being a language of
communication, XML can also serve as a checkpoint which
lets you make sure that the data you produce makes sense,
and which lets me make sure that my transformation and
presentation algorithms are indeed a good match for this
data.

Shouldn't a designer primarily be interested in the
way the data is modelled (e.g. in the database), and,
in a later stage, whether an application produces the
right results, that are as I understood the ones the
programmer passes to the designer in XML format.

Cheers,

Gian Franco

[Axel Janssen]

Originally posted by Dmitry Kirsanov:

but if you actually try it you'll realize how much more elegant and modular the system becomes - and how many problems it had before

But isn't it also job of programmer and designer to provide the user with a responsive application. Aren't those xml-serialiazation/deserialization stuff processes which slow down system heavily?

Axel

[Dmitry Kirsanov]

> But isn't it also job of programmer and designer to provide the user with a
> responsive application. Aren't those xml-serialiazation/deserialization
> stuff processes which slow down system heavily?

Performance is only one aspect of a good application. Maintainability and clean design are just as important. What's the use of fast response times if the application is a mess? Besides, the notion of XML always being a bottleneck is an exaggeration. It is usually possible to find a good middle ground between speed and elegance.

Separating data structure and presentation is a must if you want to stay sane and scalable, and to implement such separation, you either go with XML (a standard, well supported way) or you reinvent the wheel yourself (an inevitably limited, even if potentially more performant approach). Don't fall into the premature optimization trap.

[Dave Knipp]

Dmitry,

Thanks for your reply, it really helped me understand why xml is so important. It just adds another lay of abstraction and lets the presenation layer decide upon how the data should be displayed and with what technology. Which is cool, since you could start with jsp's and then switch to some other presentation technology.

I did have some concern in regards to the performance question that was asked. I'm not so sure that building xml documents within java is such a fast task, especially if you have alot of data to transfer during a request within a web application. What if the xml document ends up have 1,000 nodes? Wouldn't this be a huge bottleneck within the transformation logic and the end result (the xml)?

I would think that building an xml document using DOM would take at least a few seconds for 1000 nodes, and that's way to long for a user to wait on a page to load.

What do you think?

Regards,
Dave

[Dmitry Kirsanov]

First of all, if you're passing a bunch of data that is to be presented as a web page, it's unlikely that you'll need a 1000-node tree because web pages should never be that huge. A complex page may have lots of nodes in its XHTML representation, but most of these are formatting, while the dynamic data it gets from the engine is usually much smaller.

Also, there are different options for communicating between a data engine and the formatter. If DOM trees are too slow for you, you can use SAX streams (the approach utilized by Cocoon). Besides, in some cases even serialized XML that is re-parsed by the XSLT processor may be fast enough.

[Alvin chew]

hi , Dmitry, i new in XML and XSLT,

my question is if xml use to store data, XSLT use for present data, do you think xml should store database's data as a good idea which allow minimise the database processing and hence benefit better speed for application ?

another question is , will XSLT present data in standard view format in different browser ?

thank you !

[Dmitry Kirsanov]

> my question is if xml use to store data, XSLT use for present data, do you > think xml should store database's data as a good idea which allow minimise > the database processing and hence benefit better speed for application ?

You can store all your source data in XML, but it likely won't give you any speedup. On the contrary it may be significantly slower. The advantages of XML are different: it's a human-readable, easy to define and validate interchange format which is therefore good for connecting different modules (such as the dynamic engine and the presentation layer), but not necessarily the best for using internally in a module.

> another question is , will XSLT present data in standard view format in different browser ?

XSLT will produce whatever you program it to. This can be HTML 2.0, MSIE HTML, XHTML. It may be even plain text of a Windows INI file if you need them.