If youĪre doing PDF output development, and you are running the output Simply doing PDF output, that cuts down the factors a lot. There are many, many things that an OT plugin can do. The OT is basically an Apache Ant application VS Code is a really nice code editor, but I doubt it knows anythingĪbout the DITA OT. And the MS link above looks like it's using Of the OT use XSLT 2, and they may even be doing stuff with XSLT 3 In the OT runs on temp files that have been processed by the OT andĪre different from the pristine source DITA files.Īlso, in looking at info on the VS Code XSLT debugger, it's hard toĪ lot of XSLT tools only support XSLT version 1. Save the temp directory created by the OT, because most of the XSLT Output, but it gives some background on what you would need to do to That topic is for using Oxygen's xslt debugger, and it's for PDF For general info on what's involved in something like this, see Then probably run the xslt on the xml file separately, outside the You would need toĭetermine which XSLT from the OT was being run on what XML file, and Import .I have not used the VS Code xslt debugger. So, we'll start with extending the SAXParser class. We can extend the standard Xerces parser to insert trace calls in xsl:template bodies. It declares methods like startElement, startCDATA, endCDATA and allows clients to implement custom XML parsers. XMLReader is a Saxon compatible SAX interface. What if we could insert the trace calls dynamically, taking the guesswork out of debugging? The good news is that we can. What is more, XSLTTraceListener can be extended to produce pretty HTML reports. It can be stored, analysed and transformed as XML documents normally can. The good part about the trace output is that it's XML :-). But what are the advantages over using xsl:message? It's even worse, since the output is more verbose. We have managed to combine source and stylesheet information within a single output. I can also complement the trace info by adding user trace calls. tTraceListener(new XSLTTraceListener()) Ī trace is printed to standard output as a well-formed XML document. XsltTransformer xsltTransformer = // Initialisation code Today we are interested in net.sf., a standard implementation of TraceListener, which gathers tracing info from XSLT stylesheets.Ĭommand line usage: java -jar saxon9he.jar -T: net.sf. But soon we'll find out how we can benefit from it, too. It is also put to good use by XQuery developers, because they don't have such a tool as xsl:message. It can be used, for example, in performance analysis. Net.sf. is Saxon interface to collect tracing information. But what if I'm dealing with a really complex module with modes and priorities? XSLTTraceListener This method can work if I'm familiar with the code base, which is additionally relatively small. So I estimate which templates might be in use and insert instructions like: And I want to visualise the relation between source nodes and their matching templates.Ī solution which immediately comes to mind is to use xsl:message to collect debug info. I have a source document and a quite complex transform. We'll only need Saxon HE, Xerces and some knowledge of Java. In this article we'll discuss how to build a personal back-mapping solution for everyday needs. Unfortunately, not all the tools are equally convenient, plus, they cost money, and it often takes time to learn and tune them. So, how can I debug it? Modern XML editors provide excellent XSLT debuggers, and there are back-mapping solutions available on the market. Hmm… What does the xsl:next-match above do? Where does it redirect to? It was me who wrote the code, but I hardly remember what I meant. Have you ever found yourself spending hours trying to track down a transform problem? Especially, when working with a messy or ill-structured XSLT module? Know-how: Debugging complex XSLT modules 30 June 2016 on XSLT
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |