Re: portability. (Re: microsoft latest, bug with extension e

>  > 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