Re: Saxon VS XT

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