I would agree with that=2E
> (if I had a Java development environment, I would probably have
> altered the way XT spits out the result tree)
Would you not consider this to be providing you with more control? Beyond=20
simply producing the output you require=2E
I guess my comments were aimed at the nature of the control and=20
implementation as opposed to which XSL was being used=2E I find that the XT=
=20
java approach allows the construction of scalable and managable solutions=2E=
=20
For example, its easy to pass an InputStream to XT from either a URL or a=20
serialised Grove or something else=2E The MSXSL ctrl's COM interface is=20
limited and non-extensible=2E
I believe that seeing how a thing works and having the ability to modify or=
=20
extend it is a powerful thing=2E Consider a situation with a large XML or =20=
XSL=20
file, if the MSXSL ctrl can't handle it, it can't handle it and there's not=
=20
alot you can do without the solution being contrived=2E With an open OO=20
solution you have the power to solve the problem without breaking the model=
=20
or imposing future constraints=2E
graham=2E