Reevaluating XSLT 2.0  Hot PDF Print E-mail
Tag it:
Delicious
Furl it!
Digg
NewsVine
Reddit
YahooMyWeb
Technorati
Articles Reviews XML
Written by Kurt Cagle   
Saturday, 10 March 2007

{mos_sb_discuss:24} 

I recently wrote a blog about the directions that I saw with XML, and while it has proved to be fairly popular, it has also generated a fair number of comments that really need their own more detailed examination. One of these, and one that I’ve been planning to write for a while anyway, has to do with my comments about XSLT 2.0 increasingly being used as a “router” language, replacing such applications as Microsoft’s BizTalk Server.



This is not a disparagement of BizTalk - it’s actually one of the Microsoft technologies that I have actually endorsed on a regular basis, because it solves one of the thornier issues involved in creating complex data systems - how do you handle the intermediation of data coming from different data sources, and while I have some quibbles about the interface, I think BizTalk does its job admirably. It also served as a bridge technology for quite some time between the SQL and XML worlds, and it will continue to serve in that role for quite some time to come.

However, I also think that in the long run it is a bridge technology, and that as the world moves increasingly to the use of XML as the preferred data transport story, other technologies, such as XSLT 2.0, will likely end up making most of it functionality redundant and useful at best on the edge cases.

Such statements presuppose a lot, of course, most notably that XML is in fact becoming the dominant form for expression of data content. Before digging into XSLT2, I’d like to address this issue head-on, as it ties into a number of other things I’ve been looking at of late.

SQL is very good technology, and a fairly remarkable standard. SQL is not going to go away, nor should it - SQL, and related standards such as LDAP or OLAP, are specifically defined to provide rapid access to relational data in a way that XML will never be able to do by itself, because the assumptions made with XML include the tacit assumption that you are replacing efficiency with flexibility.

A system that is too flexible becomes unwieldy because it fails to constrain the problem domain sufficiently - I can make a program do just about anything at the beginning, but the moment that I start defining what that “anything” is and how I can accomplish it, I perforce also reduce the ability of that application to do other things as well.

This is the sculptors dilemma - a block of stone can in fact contain a near infinite number of things before the first chip is made, but by more clearly defining what the sculpture is you also cut down dramatically on what it is not.

XML assumes a fairly broad definite of data structures and as such is nearly infinitely malleable, but once you start defining the data structure, this places sizable constraints upon what the structure isn’t.


User reviews

There are no user reviews for this item.

Add new review




Powered by jReviews

Last Updated ( Sunday, 08 July 2007 )
 
< Prev   Next >