evanlenz/xslt-visualizer

Home for a grand experiment in software visualization for XSLT.

xslt-visualizer's Issues

Use CLASSPATH in the scripts

Instead of a hard-coded path to the Saxon jar file 😳

Add key-based navigation

For example, use RIGHT, LEFT, UP, & DOWN arrow keys to navigate the transformation. RIGHT and LEFT could go forward and backward in depth-first order (like "stepping into"). DOWN and UP could go forward and backward in breadth-first order (like "skipping over"). This would enable seamless switching between stepping into and skipping over without having to manually change a global setting. Perhaps we would still use the existing scheme (with the "Breadth first" toggle), but that toggle would automatically get changed back and forth when the user hits an arrow key that changes it.

Consider how to handle long key presses. Right now, with the slider activated, long key presses eventually move the slider but you don't get to see the intervening movement, because the performance is poor and it freezes up. The scrolling animations could be part of the problem with their built-in delays. Perhaps the delays could be suspended (or shortened) during a long key press.

Consider also whether breadth-first traversal would be constrained, i.e. not automatically changing depth without an explicit RIGHT or LEFT key press. There might be some compromise between the UI doing something every time you hit a key vs. resisting when you hit a "dead end", e.g. stopping when you get to the last sibling (when pressing DOWN) or when you get to the first sibling (when pressing UP). The tree could be thought of like a network of walls/paths. Some keys force you to stay within the walls; some keys allow you to fly over them. Sometimes it can be frustrating to get stopped. Sometimes it can be frustrating to get lost because you didn't get stopped. Provide solutions for both.

More thoughts about intuitive tree navigation would be great. Transformation navigation is tree-centric (specifically result-tree centric). But you could also make it source-tree or stylesheet-tree centric too. The difference is that, whereas a node in the result tree corresponds to just one focus, a node in the source tree (or rule in the stylesheet tree) may correspond to multiple foci: a rule for multiple source nodes, or a source node for multiple invocations of the same rule or of rules in a different mode. Anyway! More thought on this would be good. Explore the many ways to explore a forest.

In example scripts, use CLASSPATH instead of hard-coded path to Saxon

This of course becomes obsolete if we replace the example shell scripts with an XProc pipeline (or even an XSLT-based runner, using transform(), hmm...)

Somehow depict the current node list

E.g. through additional colored lines with a lighter hue of the same color

Brainstorm other potential ways to visualize that context.

Create an XProc pipeline to generate visualizations

Dispense with the bash scripts.

mode attribute is missing end quote in rendition of apply-templates

E.g.:

<xsl:apply-templates mode="markup select="detaileddescription"/>

Don't require MarkLogic

Support Saxon-HE, for example.

Make visualization states addressable

E.g. through a URI fragment identifier that dictates the slider position and option settings.

Make XSLT snippets prettier

Consider using something like https://github.com/pgfearo/xmlspectrum

Don't create lots of intermediate files

Find another way to create side effects in Saxon-HE (besides using xsl:result-document to write them all to the file system). The tool currently outputs a separate file for every instantiation of a template rule, and this can get unwieldy with larger projects, especially with anti-virus programs having to scan so many newly-created files.

It looks like fn:transform() will work to do just what we need for this. Work is in progress...

Failed to create output file

See here: boostorg/docca#66 (comment)

Support stylesheets with different output methods than XML

The solution for #5 raised a problem for trace-enabled stylesheets that output a different format than XML (such as text). When the delivery-format for transform() is "document" (the default), the output method of the user stylesheet is disregarded.

I have a solution pending that uses "serialized" as the delivery-format, but that runs afoul of an apparent Saxon bug that gets exploited when, for example, xsl:output/@method is "text". Keep the solution around in disabled form for when the bug has been fixed for a while (or I learn what I might have been doing wrong).

In the meantime, provide a workaround that enables us to pass in the principal-output-method as a parameter to run-trace.xsl. Yes, we have to repeat ourselves, but it's not too big a deal as far as workarounds go.

Visualize temporary tree constructions

Currently the tool doesn't support visualizing the application of template rules if they are done in the context of an xsl:variable (or xsl:param) evaluation. We can't just use xsl:result-document like we do for visualizing the primary output, because that instruction is not allowed when constructing a temporary tree. Other possibilities would be to define an extension function specific to Saxon (which could access the value of tunnel parameters, etc.), use fn:trace() or xsl:message and post-process, etc. Whatever method is used, we might want to apply it universally, replacing the use of xsl:result-document.

Begging the question is how the UI should visualize temporary tree constructions (pop-up window? embedded pane? etc.).

Support user stylesheet parameter initialization

Use case: passing through DEBUG=yes to a trace-enabled user stylesheet so that the primary result it creates can know to add a link to its visualization page.