[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: questions about XSLT philosophy: how much is too

Subject: RE: questions about XSLT philosophy: how much is too much?
From: "bryan" <bry@xxxxxxxxxx>
Date: Thu, 20 Mar 2003 11:00:37 +0100
RE:  questions about XSLT philosophy: how much is too

> >speaking from the perspective of a rank newcomer, it's getting
> >a bit overwhelming to see how many different problems people
> >are trying to solve by shoehorning them into an XSLT issue.
Trying to solve - or solving? 

This smacks of "if all you have is a hammer".

I've never really liked this attitude as it often seems to be used as  a
rhetorical tactic with which people who are not familiar with a language
can control others usage of it in a working situation. 

If I can swing that hammer better than someone else can work their whole
toolset then I submit that the hammer may be the superior tool in the
situation at hand. 

Of course this argument has more to do with code maintainence than it
does with code creation. Code created with the hammer of the gods cannot
be maintained with the hammer of jones from down the block.
And there has been a lot of argument about xsl-t's maintainability, I
have come to the conclusion from an experience that I had recently in
re-using a generic xsl-t for xml schema presentation, and one for rdf
xml presentation,  that it is just as maintainable as other code, but
that not very many people use it at the level required to make what they
produce worth maintaining; the xml-schema xsl-t could be adapted to a
new framework with a minimum of reworking, the rdf xml was not worth
keeping and had to be rewritten.  


 In the case discussed earlier the guy created some product with shell
script, this was argued as being inappropriate usage of shell scripting.
If it was his product, and he was going to maintain it, and it worked
better than other products in the field, I submit that shell scripting
was the proper tool.

I use a lot of different languages in a week, my choice of xsl-t for the
solution to a problem might seem to be the wrong one to someone with a
lesser understanding of the problem than I have, conversely it may seem
wrong to someone with a greater understanding. The proof will always lie
in the solution. I don't make many mistakes with xsl-t anymore, and I do
use it to solve many things that provoke hammerism in those who would
prefer to use their own favorite hammer in lieu of mine. 
The usage of a new tool for what is a standard solution area, with
well-understood solutions, can provoke new and interesting
architectures, and, at times, superior solutions. 


Excuse me if I ranted. 



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.