|
Re: [xsl] XSLT Dead?
2007-04-16 16:50:05
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(_dot_)online(_at_)xs4all(_dot_)nl>
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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
|
|