I'm having trouble with an XSL translation in Chrome. I was wondering if there any tools that would allow me to step through the style sheet to see where the problem is.
-
I think there isn't. Maybe if you ask about your specific problem we might give you an answer. – Apr 19 '11 at 15:52
-
Sorry, I'm not able to give specifics about my issue. I was hoping to ask the question generally in the hopes that I can help others solve XSL problems of their own in the future. – Bryan Apr 19 '11 at 23:37
-
Any kind of debugging advice would be great. – Bryan Apr 19 '11 at 23:38
2 Answers
- Use node tests to check the results of XPath queries.
- Use the document function to test file paths
- Use the JavaScript console to run XPath queries on the XML data source
- Use inline templates instead of
xsl:include
to eliminate path issues - Use comments to eliminate
xsl:include
statements referencing buggy templates - Use processing-instructions to comment blocks of code that have XML comments
- Use an embedded stylesheet to workaround same-origin policy restrictions
- Use
input
tags to printxsl:variable
values. - Use attribute value templates to print unknown values
- Use simplified stylesheets and parameterized XPath to modularize templates
- Use Opera as a cross-reference, since it shows line numbers in its XSLT error messages.

- 24,148
- 7
- 127
- 265
On linux there is a tool called xsltproc which takes an XSL and XML and outputs the transform.
It also shows context around errors.
I've found this most useful when I'm developing as I can test the result of my changes without the need to have a development server up and running. It just works.
However, I've noticed that the results of the transform can differ from that of Chrome for example. I don't know why this is, whether my transform was non-conforming, if Chrome is non-conforming, or if xsltproc is non-conforming.
EDIT My comment about differences between Chrome and xsltproc rendering the transform slightly differently is likely invalid.
- I had modified the XML schema somewhat, and since then, xsltproc was generating tags (based on type name of types in the schema) correctly, but Chrome was not.
- I was doing hard reloads to avoid Chrome reusing the cache.
- I could tell Chrome was using the new xsl as there was other changes included that were being rendered.
- Only the schema related tests were not working in Chrome for some reason.
- I've since found that now it is magically working, with no changes to the xsl, just on a different day.
So I guess some part of the xsl was being cached somehow (perhaps just the schema bit - totally guessing here)... hence why some debugging in Chrome would be super nice.

- 532
- 2
- 12
-
What kind of difference do you notice? AFAIK, Chrome uses the `libxslt` processor, which is also used by `zsltproc` - so any differences should be very minor, possibly due to different versions. --- In general, the XSLT specifications leave several things as "implementation dependent" - so a difference in behavior does not necessarily mean non-conformance. – michael.hor257k Nov 08 '22 at 06:06
-
Thanks for asking, I need to follow up on this. I'll edit my answer to clarify. – d.j.yotta Nov 09 '22 at 23:51
-
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. [What topics can I ask about here?](https://stackoverflow.com/help/on-topic) You should vote to close this old question, not answer it. [answer] – Rob Nov 10 '22 at 00:21
-
I have no interest in voting to close this question. My extensive internet searching ended up here, and to another similar question which I linked back to this. I think it's good to have all the answers to this question in one place wouldn't you agree? – d.j.yotta Nov 12 '22 at 19:59