Re: Which engine? (RE: JavaScript and XSL)

[Paul Tchistopolskii <paul@xxxxxxx>]

From: G. Ken Holman <gkholman@xxxxxxxxxxxxxxxxxxxx>


> 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