I very much like the idea of pointing the VSCode debug environment at an arbitrary TDML file, and seeing it put up a list of tests I can choose from to debug. Even if it only supports test cases where the schema, input data, and expected infoset are all in external files (at least initially).
Symmetry then suggests that yes, one must be able to save out a debug session as one of those TDML files as well. Or add a test to a TDML file. Services in the daffodil server (scala side) to support this do make sense to me. The CLI doesn't let you create a TDML file today, but it does let you run one, list the tests in one, or run just one (or those whose names match a regex). Creating a TDML file or appending to one is logical, though more awkward, from the CLI, whereas it would be a natural thing to do from the VSCode IDE. One challenge is capturing the class path. TDML files don't capture this (currently, maybe they should?), but when a DFDL schema is an assembly of other schemas, the class path is what ties them together. Right now, a DFDL Schema project consists of DFDL schema files, test data files, test result files (XML), a TDML file, and a build.sbt file which specifies any dependent schemas as managed dependencies. Seems to me a VSCode debugger project needs IDE config information (users's current screen layout, open files, etc.), plus all these things, or in the case of the build.sbt file, enough information to generate it. (I would not recommened using build.sbt's syntax as a way to store that information, as then you'd need to be able to parse it back.) Right now a TDML test just references a "model" as in the primary XSD file of a DFDL schema. The ability of daffodil to find the rest of the schema from there depends on the classpath, which is constructed (by the CLI) using the DAFFODIL_CLASSPATH environment variable. For an sbt test run, sbt constructs the class path based on managed dependencies specified in the build.sbt, and the directory tree of the project as described by sbt as unmanagedSourceDirectories, unmanagedResourceDirectories, unmanagedSources, unmanagedResources for both Compile and Test objects. (These often just are the default values of src/main/resources, src/main/scala, src/test/resources, src/test/scala, but we also have build.sbt that use just src and test directories with no substructure.) E.g., if you execute sbt new apache/daffodil-schema.g8 So we need more than just the TDML file, or may need to enhance the TDML file to incorporate more top-level information. I'm not sure. -mikeb On Thu, May 12, 2022 at 12:12 PM Mike Hoke <michael.h...@nteligen.com> wrote: > All, > > I'm looking into implementing TDML Generation into the Daffodil VSCode > extension (https://github.com/apache/daffodil-vscode/issues/10). It > occurred to me that this might be a useful feature to have in the daffodil > CLI tool at some point in the future. If that is something that will be > wanted, I think it makes the most sense to implement this feature in Scala. > If it doesn't, I'll likely just look to implement it specifically for the > extension in Typescript. > > Any feedback would be appreciated. Thanks, > Mike >
