TDML Roadmap

[michael-hoke]

This discussion is intended to be a reference for where the TDML feature set will be going. See the following tickets for pieces: daffodil-vscode #594, daffodil #1057, daffodil-vscode #595, daffodil-vscode #596, daffodil-vscode #811

JAXB Bindings

The first major change will be to move the JAXB bindings from the VSCode extension into daffodil. This is (hopefully) nearly complete, and we are hoping to make it into daffodil's next release. Once that happens, we can remove the bindings from the daffodil-vscode codebase and pull the generated bindings from the appropriate daffodil-jar. This will likely require a minor refactor in the existing backend TDML code.

GUI Editor

The next major change will be to add a GUI editor for TDML into the extension. The first thing to include is language support for TDML. This is not intended to include autocomplete/intellisense - language support, in this context, means that VSCode is able to open a tdml file and properly identify it as TDML language. This change will include a GUI interface for modifying a TDML file.

Extremely crude sketch of what the GUI could look like:

On the left, there is a list of all test cases in the currently opened document. This list should dynamically resize when test cases are added/removed. There should also be a button to add a new test case. The center contains text boxes for the name/description of the current test case. The text box should only become editable when appending a new test case. If VSCode supports this, add "suggestion" text to the text boxes when initially switching to append a new test case. I can't remember what this is actually called, but it puts text into the text box, even though the text box thinks it is empty. We should put the current default name/description here. We want to provide some sort of help to the user on what to put in the fields, but we don't want them to have to select and delete our sample text. If the append button is clicked and a field is empty, we should use our default when creating the new test case. The 'Append Test Case' button should be disabled (or even removed?) when viewing an existing test case.

Does it even make sense to have some of this edit/append functionality? What is the use case for a user actually using these to add a manual test case or editing an existing test? Do we need to add some kind of smart check to make sure that the files exists before we allow the edit to go through?

I think we should make edit/delete semi-hidden - either behind a right click of the test case on the left side or through the command palette. Clicking on an existing test case should treat the test case as read only. If the user wants to edit, they can use whatever mechanism we end up using... This definitely makes sense for delete, but edit?

The 'Raw View' button at the top right simply hides the GUI in favor of the 'default' raw text view of the TDML file. This button should be an afterthought. If we cannot easily provide this, we should drop it from this ticket's scope and create a new ticket to add it.

Other Changes

IMPORTANT: See daffodil-vscode #625 for naming suggestions. We can use this opportunity to rename our variables to lessen confusion down the road.

• Add tdmlConfig back into the launch config. It should be optional.
• 'Generate' should be the default action.
• 'None' should be a valid action. I think the use cases for this are going to be disk space (extremely unlikely) or a bug, where a user needs to disable TDML generation because it is preventing them from using the rest of the extension.
• We should not need to specify a location for the TDML file. We should always put it in /tmp (or OS equivalent) under a static name
• We should provide 'Cleanup TDML File' and 'Copy TDML File' actions on the command palette.
• Cleanup TDML File should remove the TDML file under /tmp
• Copy TDML File should copy the existing file to the user-defined location under $workspace.
• There should be an Append/Copy option that takes the test case from the file under /tmp and appends it to the user-defined location under $workspace.
• Remove Generate TDML from the command palette
• Remove Append TDML from the command palette
• Add a command to create a zip file in the command palette. This should take all files referenced in all test cases in the currently opened - TDML file and zip it together, keeping relative paths intact (should just need to make sure all the folders are in the right place. The relative paths should be computed when the TDML test case is generated).
• Add duplicate checking for test cases. What is considered a duplicate? Name and description matching?

Keep in mind

If time permits, consider investigating Selenium for GUI test cases.

Add Testing Support

Using VSCode's builtin Debug Integration (https://code.visualstudio.com/api/extension-guides/testing), add the test cases in the currently opened file to this window. This might be redundant with the tabs on the left hand side... Maybe there's a way to consolidate them or have only one showing at a time?

• Remove Execute TDML from command palette. Test cases will be executed from the debug tab.

Add Stack Trace Support

This depends on having the ability to pass information back from the server to the client. In the case of an error during a DFDL parse, we should get a stacktrace. If this trace is sent back to the client, we would be able to add it into the generated TDML file

[arosien]

TDML + XML object binding update: apache#594 was closed.

Closing for multiple reasons:

• TDML XML object mapping support isn't used, or can be avoided, in downstream Scala projects like daffodil-vscode. See above for more context.
• The original JAXB solution was deemed to have too particular build configuration given differences between JVM versions, so scalaxb was chosen instead. But since JVM 21 was introduced it also appears to have JVM version dependent build configuration, which is slightly annoying. It's not a blocker, however.
• Given the oddities of XML object binding, the need for an alternative was proposed above, say, JSON, which may fit more downstream languages like Scala and Typescript.

For the future, we should remove the TDML code from the Scala backend:

• generate and append are already implemented in TS, right?
• execute is extremely simple, it reads the TDML XML file and finds the schema and data files for a given test name. Instead, the front-end could do this and then launch a "normal" parse.

It was also suggested that we could have an alternative encoding of tests, say in JSON, which might be easier to support in multiple languages.

[michael-hoke]

In order to fully remove the TDML from the backend, we should have the capability to send the "results" of a parse back to the frontend. This is because one of the next big features in TDML should be the ability to capture errors and/or the stacktrace from a parse, and that cannot be done from the frontend alone.