This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: portability. (Re: microsoft latest, bug with extension elements )?
> > This pre-processor could be a 'hardcore' XSLT stylesheet.
> > Why should you explain ? Just add one more line to the
> > script.
>
> what script? I dont have scripts.
In case you are invoking the rendering manually, yes - you have
no scripts. You are really invoking XSLT engines
manually ???
> > > 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.
>
> right. thats my compromise. and my defence is that it is explicitly
> tagged as a likely addition in the appendix to XSLT, and explicitly
> mentioned as a likely contender for XSLT 1.1. I am gambling that it
> will be standard in a year
Yes, gambling on W3C papers is exciting occupation....
( um ... pleasure? )
Are you saying that all those XSLT engines you are
supporting already have this feature? Or you are talking
about *very* limited number of XSLT engines ( say, 3 ? )
I'm having problem to understand what do you mean when
saying that you are writing portable XSLT stylesheets.
> > Much better is to use redirects ( every OS allows > )
> I dont see the relevance, to be honest
When you need multiple outputs, invoke multiple
stylesheets. Write a script. ( How your gambling
helps you with current versions of XSLT engines -
I don't understand ).
> > If you want to be portable, I think you should never
> > use those <xt:document and alikes.
>
> no, I shouldn't. But I have to. it really isn't plausible to build a
> real system without such a functionality.
Yep. That's why "portable XSLT" looks impossible to me.
Cause I can say the same about Java extensions.
In Ux I have to stop using xt:document, cause
it will never work in SAX mode ( replacing it with
Ux > redirect ). Ironically I now think it is better not to
use xt:document anyway ;-)
> > > For the rest, I'll use node-set when it gets into
> > > XSLT formally, but otherwise not in public.
> >
> > Don't understand this.
>
> my TEI stylesheets dont use node-set, but my stylesheets for
> gravestones do. why? cos anyone can use my TEI ones, but no-one else
> will ever see my gravestone ones
Well ... I hardly understand how can I live without
node-set, but that's because I'm embedding. When
stylesheet is not using extensions, the need for node-set
should be low .... I think I now understand what you mean.
> > 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.
>
> sorry, I don't see why its *much* harder. if I isolate my use of
> saxon:output to one named template, its no big deal to maintain and
> port that.
I agree. You can isolate saxon:output. I need to think better
what I meant to say here - there should be some rationale -
trust me ;-)
> > SAXON is MS of XSLT and I'm already having problems
> > with that.
>
> but where is your evidence of the widespread use of Saxon?
Sometimes it does not matter how much copies are installed,
but it is more important *where* those copies are installed,
I mean what engine is used by developers who are building
'on-top-of'. I think after XT has been 'dropped' many people
are building on SAXON. As I said, if XT not exist - I'l myself
start building on SAXON with no question. And when you
have saxon:evaluate it is hard to resists using it ;-)
Rgds.Paul.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list