This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Which engine? (RE: JavaScript and XSL)
From: G. Ken Holman <gkholman@CraneSoftwrights.com>
> At 00/10/17 20:18 -0700, Paul Tchistopolskii wrote:
> >XT is dead, I think. It has no saxon:evaluate ;-)
>
> I do not believe the measurement of the value of an XSLT processor is in
> the support of a proprietary extension.
Let me see...
> XT is just fine for many people. Personally, I use the key() function
> quite a bit so for that reason I am obliged to use other processors for
> some of my more recent work
This means you do belive that the measurment of the
value of an XSLT processor could be in support of key() function.
Right?
> I feel your implications of needing to support proprietary extensions may
> be misleading to those new to the technology.
And the critical difference between key() and saxon:evaluate() is ... ?
I think the only difference is that one thing is written
on paper published on W3C website and another is not.
To me this means there is almost no difference.
key() is optional, like saxon:evaluate is.
If you don't like saxon:evaluate I may recommend thinking about
saxon:preview
For many cases ( when there is a need to process a big file
with XSL ) saxon:preview is the *only* possible workaround
( if you want to stay with XSLT of course )
key() could be always replaced with pipe, saxon:evaluate
could be replaced with 2-step transformation, but it is simply
impossible to process a really big file with XSLT *not* using
saxon:preview ( and of course saxon:preview is not a
universal solution but at least it gives some hope ).
Whatever. Of course XT is dead not only because it has
no saxon:evaluate.
Rgds.Paul.
PS. However, the value of saxon:evaluate is underestimated
and I think it is one of the bombs inside XSLT.
There are many bombs and many of those bombs were
sound on this list.
For example.
I'm constantly contacted by different startups who are
trying to utilize XML in some middle layer ( you know -
connecting 2 legacy systems with XML ).
Of course I constantly try to use XSLT for this. It usually fails
*not* only because of memory limitations, but, for example,
because there is not too many low-paid slaves who
understand even simple principles of functional programming.
Because most of coding in current IT is done by low-paid
slaves - XSLT usually gets rejected for the sake of custom
SAX parsers, even it is a clear understanding that it is
better to use the stylesheets !
( Architects and managers who are making such decisions
are not morons at all. They just have a real deadlines they
should make. )
I'm not kidding.
I don't think that I'm very weak XSL coder, but in some cases
( even after a year of writing XSLT code ) I'm just thinking:
"should I spend some time on this transformation or I'll better
to write a bunch of SAX filters" ?
For many companies that I see around it is simply
*much* cheaper and faster to write custom Java code,
because java slaves are *much* easier to find and
nothing can beat Visual Age ;-)
I agree - for web-development ( or for rendering
XSL FO WD ) you don't need saxon:evaluate.
( You don't need key() as well ).
For middleware? Both are important. ( I think saxon:evaluate
is more important ).
This is all side-effect of the most important bomb: "Is
XSLT only for rendering Web pages or not?"
If it is - what the heck is Schematron ( and some
other things ) ?
If it is not - ... well ... ask people who are using
XSLT for things other than rendering Web pages -
and I bet those people will tell you:
Could you please let saxon:evaluate and
saxon:preview in ?
The problem domain of XSLT is unknown.
*This* is *really* misleading. Comparing to *this* I'm
not misleading at all.
Rgds.Paul.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list