I have not used the VS Code xslt debugger. You would need to determine which XSLT from the OT was being run on what XML file, and then probably run the xslt on the xml file separately, outside the OT. For general info on what's involved in something like this, see this Oxygen topic:toggle quoted messageShow quoted text
That topic is for using Oxygen's xslt debugger, and it's for PDF output, but it gives some background on what you would need to do to get the right XSLT and XML files. For example you probably need to save the temp directory created by the OT, because most of the XSLT in the OT runs on temp files that have been processed by the OT and are different from the pristine source DITA files.
Also, in looking at info on the VS Code XSLT debugger, it's hard to see what version of XSLT it supports:
A lot of XSLT tools only support XSLT version 1. Late model versions of the OT use XSLT 2, and they may even be doing stuff with XSLT 3 (not sure about that). And the MS link above looks like it's using the XSLT processor that comes with .NET. The OT uses the Saxon XSLT processor, which is Java-based.
VS Code is a really nice code editor, but I doubt it knows anything about the DITA OT. The OT is basically an Apache Ant application that calls Java code and XSLT code. I don't know of a debugger that traces what the OT itself is doing. And I know of no "OT plugin debugger".
There are many, many things that an OT plugin can do. If you are simply doing PDF output, that cuts down the factors a lot. If you are doing PDF output development, and you are running the output over and over again, you can cut down your source files to get the shortest possible build times. You might run the OT from the command line to speed things up.
Also, if you are using Framemaker for PDF, why aren't you using the Fm PDF capability? Just curious.
Mark Giffin Consulting, Inc.
On 12/10/2019 11:39 AM, nyxys21@... wrote: