xsl-list
[Top] [All Lists]

Re: [xsl] XSLT Dead?

2007-04-16 16:55:17
On 4/16/07, Robert Koberg <rob(_at_)koberg(_dot_)com> wrote:

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.

I don't follow you.  Can you elaborate?

On 4/16/07, Robert Koberg <rob(_at_)koberg(_dot_)com> wrote:
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>
--~--



--~------------------------------------------------------------------
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>
--~--

<Prev in Thread] Current Thread [Next in Thread>