Re: Accessing a node name from within <xsl:attribute>

Subject: Re: Accessing a node name from within <xsl:attribute>
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Fri, 07 Jul 2000 10:10:01 -0700
----- Original Message ----- 
From: Pawson, David 

> Paul Tchistopolskii 
> >b. You are realy novice who thinks that "MS IE has XSL".
> >In this case you should immediatly do what Michael
> >suggests  you to do! (  I mean you should separate 
> >hype from reality  and install the second XSLT engine 
> >today ;-) It could be Xt or SAXON ;-) 
> After my experience this week I'd suggest Saxon.
> Reason?
> James product takes a Unix approach, if you don't know
> what you're doing, don't use it.
> James appears to have taken the 'relaxed' option to
> error reporting, fully compliant with the spec I'm sure,
> but still 'relaxed' (silent reporting I think was the phrase)

I agree. :



There are also some known bugs, notably:
Many errors that the XSLT specification requires to be reported are silently ignored. 

> Mike  has taken a 'harder' approach and reports 
> errors where they are found.
> (e.g. variable in match pattern caught me out)

I belive that Mike provided the better diagnostics.

> I used xalan the other day for the first time, and it reported
> two templates which had equal priority (something I hadn't noticed).

Cool.  ( Is it marketing time for good XSL-lint, huh? ;-)
> IMHO, any new user wants as much error reporting support as
> possible. 

On one hand - yes. On another hand - if something does 
not work in XT ( even silently )  the novice user  could be 
almost 99%  sure that there is something wrong  in his 
code, but there is very small chance that he hit a bug in Xt ;-)
( If not using something described in Limitations section 
of course ).

> Hence I think I'll start to favour saxon in future, even though
> I rarely need the additional features that saxon provides
> over xt. My only real preference for xt over saxon
>  is that is shorter to type<grin/>

Because I'm a developer who is using XT as embedded 
engine, and because TraX lacks SAX mode which XT has - 
to me there is simply no question what should be used 
as embeddable engine - only XT ;-)

As I wrote yesterday in list4xt , I can write TraX in Ux 
( XT + SAX ), but writing Ux in TraX. will be harder ;-)

For 'pure' novice XSLT developer who is struggling 
with MS IE XSL-  I think  you are right  and Saxon 
looks like a good 'number 2'. ;-)


 XSL-List info and archive:

Current Thread