This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: portability. (Re: microsoft latest, bug with extension elements )?
- To: xsl-list at mulberrytech dot com
- Subject: Re: portability. (Re: microsoft latest, bug with extension elements )?
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Tue, 01 Aug 2000 13:03:09 -0700
- Organization: The Qub Group
- References: <C183CC073051D31184DA0008C707BBF00B0BD581@RED-MSG-41><14725.53871.769174.527424@spqr2.oucs.ox.ac.uk><009901bffb27$f9095d20$5df5c13f@PaulTchistopolskii><14725.58876.761068.743280@spqr2.oucs.ox.ac.uk><011001bffb69$cd5b16e0$5df5c13f@PaulTchistopolskii><14726.36614.402755.391176@spqr.oucs.ox.ac.uk>
- Reply-To: xsl-list at mulberrytech dot com
----- Original Message -----
From: Sebastian Rahtz
> Paul Tchistopolskii writes:
> > > more to the point, I want to distribute my TEI stylesheets so that
> > > they'll be useable by any processor (to the best of its ability)
> > > without any further ado.
> >
> > Sounds like very exciting occupation. I'l be glad to know
> > how far will you get ( I gave up long time ago because
> > of extensions ).
>
> I would not say it is my "occupation". perhaps my pleasure.
Well, if you are supporting only some subset of XSLT engines
it could be 'pleasure'. If you are trying to support everything
which has a word XSLT in the name - this could be occupation.
> > Maybe what you meant to say is "useable by some number
> > ( 4? ) of XSLT processors" ?
> more like 7 ?
How much XSLT engines do we have? I think it is more
than 10 ( and I'm sure there will be more ).
Are you supporting all of them ?
> > Honestly - the simplest workaround I see is
> > to write 'extremely portable XSLT-stylesheets'
> > ( I think this task is a bit hypotetical, but whatever )
> > is to write them not in XSLT, but to use the
> > preprocessor.
>
> but then I have to distribute the pre-processor, and explain how to
> use it. I agree it would be sensible, but it would be been better if
> I could avoid it.
This pre-processor could be a 'hardcore' XSLT stylesheet.
Why should you explain ? Just add one more line to the
script.
> in my setup, the really vital extension is multiple output files (in
> HTML mode).
Well - very bad. This is not a standard at all and it is
suspicious to write a *portable* stylesheet using
non-standard and for sure not portable extension
elements.
Much better is to use redirects ( every OS allows > )
> I just cannot do any good without that (unless I used pre
> or post splitting).
If you want to be portable, I think you should never
use those <xt:document and alikes.
> For the rest, I'll use node-set when it gets into
> XSLT formally, but otherwise not in public.
Don't understand this.
> > BTW. I see some other problem here. ;-) The problem is "SAXON is
> > MS of XSLT" ;-) People are already building on top of SAXON's extensions
> > and this kills almost any way to port their stylesheets to any
> > other processor.
>
> I know what you mean, but do you see a lot of evidence that the
> practice is so prevalent?
> Personally, I find it fairly easy to steer clear of temptation.
No you did not. You are already using <saxon:document - or whatever,
I don't know what is the name of this beast in SAXON , but I know
that porting something polluted with extension elements
is *much* harder than porting something polluted with extension
functions.
> And lets be clear that Mike Kay does not
> *promote* such a thing - so far as I can see, he simply finds it
> interesting to investigate and implement possible extensions to XSLT,
> and its a good service to the community to be able to play with them.
As I many times wrote - I very much respect SAXON and SAXON's
author.
However, saying that Mike Kay does not *promote*, say,
saxon:evaluate is simply not true.
Again - I'm not saying that promotion of saxon:evaluate is
a bad thing. I'm saying what I'm saying.
SAXON is MS of XSLT and I'm already having problems
with that.
Rgds.Paul.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list