Re^4: XML::XSLT problem

I will prepare these test cases, but I've alread mentioned that these files work flawlessly with Xalan, which is a C-based validating XSLT processor. I assume that XML::XSLT is keeping with the same standard. Also, if it were simply a problem with the xsl/xml, wouldn't you think there would be a more descriptive error, such as: "element illegal" or "element {some element} not found" as opposed to a generic "element not found," as if there was no input at all?

If anyone else has had success with XML::XSLT, please post your code; I'm certain I am just doing something wrong when calling it, but I don't know what. Thanks.

Oh, and here are the links for my current .xsl and .xml files:
XSL XML

Comment on Re^4: XML::XSLT problem

Replies are listed 'Best First'.
Re^5: XML::XSLT problem by rg0now (Chaplain) on Apr 24, 2005 at 21:45 UTC
For me it appears that XML::XSLT croaks when it tries to open an external XML file. Line 62 of `blog.xsl` confirms it: `<xsl:for-each select="document('menu.xml')/menu/item">` [download] Have you provided the file `menu.xml` for the XSLT processor? I guess you have not...:-) What really makes me wonder here is that XML::LibXSLT gives fairly sane output, even without the `menu.xml` file. Now this is really strange! Though, I admit that I am not really an expert of XSLT.... Update: after setting the `debug_callback` for XML::LibXSLT it seems that the parser just silently ignores the missing file here (only noing that the `for-each` did not produce a node list). XML::XSLT appears to be much more picky here... rg0now	[reply] [d/l] [select]
Re^6: XML::XSLT problem by bosshoff (Novice) on Apr 24, 2005 at 22:28 UTC
So, once again I am proven wrong, and I am actually happy! I totally forgot that I included a template to import another xml document. I now have two concerns: 1) Why was there not a more descriptive error; I didn't even see anything indicative of an error during import when I turned the debug switch on. 2) How do I include multiple sources into the transformation process? If I am unable to do that, things are going to get very complicated, so much so that I'm going to have to seriously rethink going back to good 'ol perl interposed with html. Thanks for all the help rg0now, I probably would've thrown in the towel without your analysis.	[reply]
Re^7: XML::XSLT problem by rg0now (Chaplain) on Apr 24, 2005 at 22:38 UTC
1) Why was there not a more descriptive error; I didn't even see anything indicative of an error during import when I turned the debug switch on. I am absolutely with you on this issue. I know that you are restricted to use XML::XSLT, but maybe it would be more beneficial to somehow migrate to XML::LibXML & co., because, for me at least, it have proven itself much more usable over the years. Also, it allows you to process multiple source files with the same stylesheet without reparsing (if this is what you aimed in point 2)), but I myself have never had to do such thing in reality... rg0now	[reply]
Re^7: XML::XSLT problem by gellyfish (Monsignor) on Apr 25, 2005 at 09:36 UTC
The answer to your first question is that it looks like a bug in the implementation of `document()` (the actually error is coming from XML::Parser because it is not able to open the file.) I'll have a look at adding a test case based on your example and see to fixing it for the next release. If you send me an email with examples of failing XML and XSLT then it will probably help expedite matters. As to your second question you probably want to try setting the `base` argument to the XML::XSLT constructor to the location of your files. /J\	[reply] [d/l] [select]
Re^8: XML::XSLT problem by bosshoff (Novice) on Apr 25, 2005 at 14:09 UTC