Subject: Re: [xsl] XSLT Dead? From: "Karl Stubsjoen" <kstubs@xxxxxxxxx> Date: Mon, 16 Apr 2007 16:54:56 -0700 |
One more thing though, I wonder if some folk do a disservice to people like Karl. It definitely seems there are people who know that almost everything can be done in XSL, but don't mention that perhaps it shouldn't.
I mean a comment like, "if it is XML, it should be transformed with XSL..." It just seems wrong.
Dang... just reading this now. I would love to comment, but Abel said what I would have said. :) One more thing though, I wonder if some folk do a disservice to people like Karl. It definitely seems there are people who know that almost everything can be done in XSL, but don't mention that perhaps it shouldn't.
I mean a comment like, "if it is XML, it should be transformed with XSL..." It just seems wrong.
-Rob
On Mon, 16 Apr 2007 18:59:23 -0400, Abel Braaksma <abel.online@xxxxxxxxx> wrote:
> Karl Stubsjoen wrote: >>> >So, is XSLT dead? >>> >>> What do you mean by "dead"? That no developer will use it or that no >>> supplier will make XSLT available? Or something else? >> >> Dead, as in there are better technologies to explore, like off the >> shelf solutions, a custom calendar control for example. > > Interesting choice of example. I work daily with XML, XSLT and many > other XML related technologies, but if I need a calendar control, I'd > investigate my host system and choose what best suits my needs. That way > you'd have a prebuild DHTML / JavaScript calendar control for some > intranet, a prebuild .NET or ActiveX control for a desktop system and a > prebuild paper version for on the wall. > >> >> I, the XSL enthusiast I am, would think WAY different than a .NET >> solution available for purchase. If tasked with "give the user a >> calendar so he/she can pick a date from", well knowing what I know >> about XML/XSL, I'd opt to write my own and pre-gen the data for the >> calendar as XML, probably using C# to dynamically write the XML out >> for the transformation. But you see, my solution would almost always >> include XML and an XSL transformation which is opposite of the >> developer looking for a solution already written for .NET. > > Interesting, again. I've seen a programmer choosing Assembler for > writing a Windows GUI app. He needed 4K where I needed 2M. The > difference was only that his took 3 months and mine only 2 days. Let > alone the maintenance issues. Do not use XSLT when there are other tools > that can do the job better. I can write a lexical analyzer for C++ in > XSLT, but really, I won't. > >> >> I would like ALL opinions. I myself, have made the concious choice to >> avoid the MS .NET gui path. I have made the choice to use XML and XSL >> where ever I can. > > I can understand the rather critical attitude of your co-workers. "where > ever I can" is a dangerous and often costly choice. > >> >> They are looking for the precanned solution. Its purchase vs. build, >> and they are opting to purchase. > > I agree with them: why re-invent something if it is already there? In > all but a few situations, precanned solutions will be the most valuable > and cost-effective ways, even if you have to leave out some of the very > nice options you would've build yourself in your own tool. It is a > common misunderstanding with programmers that they think they can build > something better or more useful where other companies have spend tens of > thousands of man hours before you. > >> >> >>> How does a "drag and drop GUI designer" relate to a result-tree >>> construction process based on multiple XML inputs in a declarative >>> construction-rule stylesheet? >> >> They don't. It is a shift in thinking. Much like the calendar >> example above, I make the concious choice to think results (solutions) >> in XML and XSL. > > I like XSLT, I really do. But I'd never choose XSLT where an imperative > language would make my life easier. Yes, XSLT is "Turing complete" and I > can probably make the new tamagotchi generation with it. But "can make" > is not a synonym for "should make". > > Really, choose the best language for the job. Choose XSLT if you have to > go from one structured input (XML or CSV or SAP ISU or whatever) to > another structured format (HTML, XSL-FO, CSV etc). Don't use it for the > things it isn't meant for, you can use your time for building other > creative and ground-breaking solutions. > > Good luck with your colleagues, > > Cheers, > -- Abel Braaksma
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT Dead?, Robert Koberg | Thread | Re: [xsl] XSLT Dead?, Alexander Johannesen |
Re: [xsl] XSLT Dead?, Robert Koberg | Date | Re: [xsl] XSLT Dead?, Rashmi Rubdi |
Month |