Update XSLTs for new Presentation XML format

[Intelligent2013]

As titled.

Source issues: metanorma/isodoc#610, metanorma/isodoc#607, metanorma/mn-native-pdf#770.

[opoudjis]

With the new Presentation XML refactor coming out of metanorma/isodoc#617, metanorma-iso now breaks on trying to test for STS conversion. Should I remove that integration testing, or keep it?

[Intelligent2013]

With the new Presentation XML refactor coming out of metanorma/isodoc#617, metanorma-iso now breaks on trying to test for STS conversion. Should I remove that integration testing, or keep it?

Please keep it, I'm going to update mnconvert for the test passing as minimum. If the integration testing is stopping the release, then remove it temporarely.

[Intelligent2013]

Currently, mnconvert allows to convert ISO/NISO STS XML to Metanorma XML.
Metanorma XML is constantly changing. The changes in the Metanorma XML should be reflected in the STS XML to Metanorma XML conversion rules in the mnconvert. Errors and discrepancies between 'true' Metanorma XML and converted may occur, because the conversion between STS XML and Metanorma XML is not just 'tag-to-tag' conversion, there is complex logic often. The constantly updating of conversion isn't complex task, but it takes a time.

Does the generation STS XML to MN XML directly make sense? In which scenarios it can be used?

Metanorma XML can be generated in this workflow:

• ISO/NISO STS XML to Metanorma Adoc
• generate Metanorma XML from Adoc

Could it be to drop the ISO/NISO STS to Metanorma XML conversion in mnconvert?

@ronaldtse @opoudjis any thoughts on this?

[Intelligent2013]

With the new Presentation XML refactor coming out of metanorma/isodoc#617, metanorma-iso now breaks on trying to test for STS conversion. Should I remove that integration testing, or keep it?

@opoudjis mnconvert updated (https://github.com/metanorma/mnconvert/releases/tag/v1.65.0).

[opoudjis]

mnconvert is updated to 1.65.0 on my side, but STS generation is still crashing when running rspec in metanorma-iso:

  1) Metanorma::Iso::Processor generates STS from Metanorma XML
     Failure/Error:
       MnConvert.convert(in_fname,
                         { input_format: MnConvert::InputFormat::MN,
                           output_file: out_fname || "#{filename}.#{@suffix}" })
     
     RuntimeError:
       Input: XML (test.xml)
       Output: XML (test.sts.xml), format NISO STS
     
       Transforming...
       Validate XML against XSD NISO-STS-interchange-1-MathML3-XSD/NISO-STS-interchange-1-mathml3.xsd...
       /Users/nickn/Documents/Arbeit/upwork/ribose/metanorma-iso/test.sts.xml is NOT valid reason:
       [ERROR] org.xml.sax.SAXParseException; lineNumber: 51; columnNumber: 22; cvc-complex-type.2.4.a: Invalid content was found starting with element 'fmt-title'. One of '{title, address, alternatives, array, boxed-text, chem-struct-wrap, code, fig, fig-group, graphic, media, non-normative-note, normative-note, non-normative-example, normative-example, notes-group, preformat, supplementary-material, table-wrap, table-wrap-group, disp-formula, disp-formula-group, editing-instruction, def-list, list, tex-math, "http://www.w3.org/1998/Math/MathML":math, p, related-article, related-object, disp-quote, speech, statement, verse-group, fn-group, glossary, ref-list, sec, term-sec}' is expected.
       [ERROR] org.xml.sax.SAXParseException; lineNumber: 56; columnNumber: 11; cvc-complex-type.2.4.a: Invalid content was found starting with element 'fmt-name'. One of '{"urn:iso:std:iso:30042:ed-1":crossReference, "urn:iso:std:iso:30042:ed-1":definition, "urn:iso:std:iso:30042:ed-1":example, "urn:iso:std:iso:30042:ed-1":externalCrossReference, "urn:iso:std:iso:30042:ed-1":note, "urn:iso:std:iso:30042:ed-1":see, "urn:iso:std:iso:30042:ed-1":source, "urn:iso:std:iso:30042:ed-1":subjectField, "urn:iso:std:iso:30042:ed-1":xGraphic, "urn:iso:std:iso:30042:ed-1":xMathML, "urn:iso:std:iso:30042:ed-1":xSource, "urn:iso:std:iso:30042:ed-1":tig}' is expected.
     # ./lib/isodoc/iso/sts_convert.rb:27:in 'IsoDoc::Iso::StsConvert#convert'
     # ./lib/metanorma/iso/processor.rb:62:in 'Metanorma::Iso::Processor#output'
     # ./spec/metanorma/processor_spec.rb:166:in 'block (2 levels) in <top (required)>'

[Intelligent2013]

Confirmed. I'll fix.

[Intelligent2013]

@opoudjis mnconvert updated (https://github.com/metanorma/mnconvert/releases/tag/v1.66.0).

[opoudjis]

Currently, mnconvert allows to convert ISO/NISO STS XML to Metanorma XML. Metanorma XML is constantly changing. The changes in the Metanorma XML should be reflected in the STS XML to Metanorma XML conversion rules in the mnconvert. Errors and discrepancies between 'true' Metanorma XML and converted may occur, because the conversion between STS XML and Metanorma XML is not just 'tag-to-tag' conversion, there is complex logic often. The constantly updating of conversion isn't complex task, but it takes a time.

Does the generation STS XML to MN XML directly make sense? In which scenarios it can be used?

Metanorma XML can be generated in this workflow:

• ISO/NISO STS XML to Metanorma Adoc
• generate Metanorma XML from Adoc

Could it be to drop the ISO/NISO STS to Metanorma XML conversion in mnconvert?

@ronaldtse @opoudjis any thoughts on this?

I'm sorry to say I don't have the business context for STS XML > MN XML conversion, but I agree with you that using Asciidoc as an intermediary representation makes much more sense, and I've argued for it for years in comparable contexts, for the same reason you've given: the XML may be more expressive and more formal, but it is also volatile and will remain so. The Asciidoc is simply more stable.

[ronaldtse]

@Intelligent2013 yes indeed. We can drop the STS to MN XML conversion. It's more important that we focus on what users need, which is in this use case, the ability to re-edit and re-publish STS XML.