Subject: Re: Saxon VS XT From: Paul Tchistopolskii <paul@xxxxxxx> Date: Tue, 01 Aug 2000 21:10:22 -0700 |
From: Sebastian Rahtz > Paul Tchistopolskii writes: > > > > Sebastian, I apologize, but maybe you will provide me with > > some particular usecase which can not be done > > with current XT ( + Java ) ? > > How do you do sorting and grouping? I used to have a solution in XT > which was *pig* slow. Then I switched to Muenchian keys using Saxon, > and it speeded up beyond recognition. Is that not a real case? I know about the key() ;-) I still want the *particular* usecase ;-) For example, I'm not sure that I'l abuse some part of pipe with constant sorting / grouping if I can avoid this in principle. ;-) I know XSLT is not good for sorting. For example, PSXLServlet is sorting the source XML with ORDER BY on the level of SQL - to avoid sorting on the level of XSLT. > The other obvious item is support of output encodings other then > UTF8. Yes, I can work around that. Supporting output encodings other than UTF8 is easy with UTF8 - to - some filter. If l have any need in such a functionality I'l grab one of the output handlers from 4xt.org and hack one of them. Should take not longer than 5 days. Is it a big deal ? > > I think that I can do anything in XT + Java *and* XT + Java > > solution will be faster than 'conformant' solution. > > fine for you. you can program in Java. I can't. Remeber your original claim ? "How can you live with a processor which does not implement the whole spec?" My letter says: XT has no problem as-is. > And how much faster? > I dont care if its only a few percent I think it could be significantly faster ;-) It depends on the usecase. > > This 'conformance' dance is exciting, but I still think that > > it is XT that has no competition ( at least as 'the embeddable > > XSLT engine' area > > I bow to your superior knowledge in the embeddable engine area. I don't > know to embed engines, so it doesnt affect me. If I was building > products (which I cant), perhaps I'd agree with you. Yep. And I also agree that for somebody who tries to do everything in 'plain XSLT' - of course the more XSLT features are implemented by some engine - the better. No disagreement here. > > By design, by implementation and by common sense. > yes, yes, but "common sense"??? why? It is very hard for me to explain why I think XT is very well balanced ( even not 100% conformant ), because to me common sense is something .... not easy to put down .... For example I don't like key() technique, because to me it looks like a logical hack for the sake of efficiency. > > PPS. I'll be glad if XT will be 100% conformant but I'll be glad *not* > > because I'll start using the missing ( almost useless ) features, > seriously, do you think keys are useless? To me - yes. They are not useless when / if you try to save performance trying to use 'plain XSLT for everything' That's not what I'm doing and I doubt I'l use key(). I'm also not using, for example, apply-imports, (even I understand how to use them theoretically, but inheritance has not only benefits, but some drawbacks as well. For example, navigation becomes a problem ;-) > > but only because this will allow me to say: "XT is 100% conformant" > > to those lost souls who are self-limiting themselves with pieces > > of paper published on some website. > > its a matter of degree. if we can conform without too much loss, isnt > it better to do so? In principle - it is of course better to conform. I'm not saying it is bad to have many features ( but maybe it sometimes is bad ). Unfortunately, conformance is not only solution, but it also has some problems. Ah - this all brings us far from the original issue that was : "How can you live with a processor which does not implement the whole spec?" And my point is that: "Yes, depending on what you are doing, some features of XSLT could be important to you, but XT implements very reasonable 'subset' of XSLT and I have no realy important need in anything that is not implemented in XT". On another hand implementing 'too much of XSLT' ( like SAXON does ) *also* provides some problems. It is good to be conformant , but it is not reasonable to blame XT too much for 'being not conformant' This blaming looks more political than technical to me. XT is darn good and great to use as-is even it will not ever be 100% conformant. I can not say the same about every engine. XT is realy very good ( even some places are dirty and there is almost no comments, sometimes dirty code written by one developer is better than the production code written by another developer. ) As I said in 4xt list - if somebody will really need key() in XT - he'l implement that. If I'l get payed for implementing key() in XT - I can do that. Should not be very hard. ( I just don't need this functionality for myself, that's why I've not implemented it yet. ) I think key() or not key() is not a big deal. XT is robust, XT is fast and XT is elegant ( very well balanced ) - this is a big deal, I think. Rgds.Paul. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Saxon VS XT, Sebastian Rahtz | Thread | Re: Saxon VS XT, Sebastian Rahtz |
saxon? missing, madi | Date | ?MSXML transformNode, Serg Stone |
Month |