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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format