Re: [xsl] Re: Does anyone know how to make IE less useless for XSLT developement?

Subject: Re: [xsl] Re: Does anyone know how to make IE less useless for XSLT developement?
From: "Terence Kearns" <terence.kearns@xxxxxxxxxxxxxxx>
Date: Sat, 25 Feb 2006 10:38:51 +1100
On 23/02/06, M. David Peterson <xmlhacker@xxxxxxxxx> wrote:
> Hi Terence,
> In reading back through this thread it seems I may have misjudged your
> intentions... my apologies for that.  It seemed to me you were on a
> mission to prove MSXML as a buggy hack, but it seems after reading a
> bit more of this thread you may have just been a bit frustrated by
> MSXML/IE's lack of any sort of extended error reporting, something I
> will admit has been a frustrating point for a lot of folks, including
> myself, throughout the years.

That's my fault because I got so frustrated that I penned a dodgey
subject line in my haste. No I'm not on any sort of mission and I
don't work for Microsoft conspiracy theorists inc. :)
I think the crux of the matter is the immaturity of the XSLT1 spec.
Thanks to Mr Mac for pointing that out. Making it optional for the
processor to report an error has been the source of my furstration.

I'm glad for the advice from people on this list about things like
setting up a test harness and which XSLT processors to test with. The
three that I used were Transformiix, Sablotron, and the one built into
XML Spy. I guess my XSLT development is only a small portion of what I
do so I haven't prioritised a dedicated development environement for

> One thing I think you can be certain of; when things simply do not
> make any sense, and you have no other explanation, pinging this list
> with a quick snippet of code, and a question as to what might be
> wrong, will most definitely gain you a response. :)

Well I'm glad I posted the query. I'll just use a less provocative
subject line next time. The reason why I didn't post the code is
bacuase there was so much of it, and until I went through the painfull
commenting out procedure, I had no idea which include the problem was
located in. I don't care what anyone says, the problem would not have
even made it to the list if IE had simply reported the line number and
file location. I don't expect it to be a development platform but that
error message is just not adequate.

Thanks for the tip on CTRL-refresh. I have actually tried this as well

In the end, once I located the line of code where the error was, I
looked up the usage of xsl:attribute in Dave's reference book and
found the bit about "attribute value templates". That's when I
inserted the curly braces and fixed the problem. One of the things
that makes XSLT difficult for anyone who is not a full-time XSLT
developer, is subtlties like knowing that "arguments" to XSL
directives need to be attribute value templates or literals. It is not
consistent throughout the language. It very much depends on which
directive attribute you are using.

for instance. If my source is <foo bar="choo" />

and I want to create an attribute 'choo', I can do it like
<xsl:attribute name="choo" />
But if I want to use the source to specify the name, I can use
<xsl:attribute name="{@bar}" /> assuming foo is in context
But then hang on, using he logic that the expression above is
EVALUATED, should a literal way of specifying attribute name be
<xsl:attribute name="'choo'" />
??? like you would using
but then I suppose it's like saying
<xsl:attribute name="{'choo'}" />
It's not obvious to the untrained eye. Or myabe it's just me.
I guess a good way to think about it would be to considder
<xsl:param name="choo" select="'choo'" />

Current Thread