Schema converter has code comment that omits schema name and version

[galtm]

Describe the bug

I think the src/converter-gen/xml-to-json/produce-xml-converter.xsl is looking for metadata in the wrong place, so the schema name and version will be omitted from the comment in the generated XSLT file.

The line that says

<xsl:comment expand-text="true"> METASCHEMA: { schema-name}{ schema-version ! (' (version ' || . || ')' ) } in namespace "{ $source-namespace }"</xsl:comment>

should have metadata/ inserted in two spots:

<xsl:comment expand-text="true"> METASCHEMA: { metadata/schema-name}{ metadata/schema-version ! (' (version ' || . || ')' ) } in namespace "{ $source-namespace }"</xsl:comment>

Who is the bug affecting?

Anyone who looks at the code for the XML-to-JSON converter that gets generated using the XSLT pipeline. The mistake is in a code comment, so usage of the converter is not affected.

What is affected by this bug?

The code comment is less informative than it's supposed to be. For example:

<!-- METASCHEMA:  in namespace "..."-->

instead of

<!-- METASCHEMA: OSCAL Profile Model (version 1.0.4) in namespace "..."-->

When does this occur?

Anytime the XML-JSON or JSON-to-XML converter generator is used, I think.

How do we replicate the issue?

{What are the steps to reproduce the behavior?

1. Copy a file like models_metaschema.xml from the metaschema repo to the metaschema-xslt/src/converter-gen directory in this repo.
2. Execute a transformation like the following, substituting your own path to Saxon.

java -cp "...path to Saxon-HE jar file" net.sf.saxon.Transform -s:models_metaschema.xml -xsl:nist-metaschema-MAKE-XML-TO-JSON-CONVERTER.xsl -o:output.xsl

Line 83 in output.xsl is missing information.

<!-- METASCHEMA:  in namespace "http://csrc.nist.gov/ns/metaschema/everything"-->

Expected behavior (i.e. solution)

That comment line should indicate the name and version of the metaschema.

Other Comments

I am working on unit tests in this area of the code, so I can include the fix in an eventual pull request for tests. If you want me to do that, let me know whether I should

a) Wait until I am done with a batch of tests or

b) Make a pull request for this fix as soon as I have a minimal test file that confirms the bug fix

[wendellpiez]

I think this is a touchup with immediate positive impact; indeed it falls into the 'sooner the better' category.

@galtm assuming a clear front on your side could you expedite this correction in a separate (standalone) PR against develop, which @aj-stein-nist and @nikitawootten-nist could integrate readily? That would be so awesome.

This sounds like option b), which I like very much. Thank you!

[galtm]

Sure, I'll do that. Yes, it's option b).

[galtm]

separate (standalone) PR against develop, which @aj-stein-nist and @nikitawootten-nist could integrate readily?

Created pull request #64, putting the test near the XSLT (which was one option mentioned in discussion #63).

[nikitawootten-nist]

Fixed via #64