I'm going mad. MAD. MAAAAAD!!!
Spent the whole day - and still trying - to debug a rather large transformation process through XSLT which uses about 35 different .xsl files, linked through xsl:includes and, in one type of transformation, all possible editors and parsers I've used give me the incredibly helpful and useful error message: resource cannot be located.
Which resource? On which file?
So, let's take a different approach: step-by-step debugging. And here lies the source to my madness...
XMLSpy can't do it because the [insert highly-insulting name here] that wrote the xsl's decided he should use msxsl:nodeset a bit all over the place. XMLSpy can run msxsl stuff, but can't debug it.
OxYgen (a very good XML/XSL tool) has exactly the same problem. And the native Java Parser it uses will cry foul at every chance it has, mostly with Windows-only file urls...
Stylus is just more of the same.
I'm now trying (or rather, hoping to get a chance to try) Visual XSLT, a Visual Studio plug-in that apparently supports msxsl and runs within the Visual Studio 2003 environment. But I'm already doubting it will work, as it will use MSXML .NET which is not 100% like MSXML 4.0...
And they don't send me the trial key, even after I signed off my mailbox for them to spam in a rather big form to allow me to test their tool...
MAAAADDD!! MMMMAAAADDDD!!!
Anyone knows a working MSXML-compliant XSL Debugger?
Update: exslt:node-set (Xalan) does exactly the same as msxlt:node-set, though it seems to be a bit more forgiving. I eventually got it to work, and the reason it was failing for was a wrong URL...
2 comments:
gee.. what a nightmare... unfortunately I can't help you, just stopped by to wish you good luck. :)
Thanks. I found out later I could use exslt:node-set to replace msxsl:node-set, and then use OxYgen and Xalan to debug it.
Now it's working, so let's see in a couple of hours ;-)
Post a Comment