This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Accessing a node name from within <xsl:attribute>
- To: xsl-list at mulberrytech dot com
- Subject: Re: Accessing a node name from within <xsl:attribute>
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Fri, 07 Jul 2000 10:10:01 -0700
- Organization: The Qub Group
- References: <39B19660C174D311BB9000A0C9E01C3F317F1E@corfu.rnib.org.uk>
- Reply-To: xsl-list at mulberrytech dot com
----- 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. :
http://www.jclark.com/xml/xt.html
<quote>
Limitations
...
There are also some known bugs, notably:
Many errors that the XSLT specification requires to be reported are silently ignored.
</quote>
> 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'. ;-)
Rgds.Paul.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list