Wrong requirements conversion

[Intelligent2013]

Source issue: https://github.com/metanorma/iso-19115-3/issues/28

Source MN XML:

<requirement id="cc-19115-12-1" model="ogc" type="conformanceclass">
    <title>Metadata core (ISO 19115-1)</title>

Current output STS XML:

<title>Requirement 115: Metadata core (ISO 19115-1)</title>

Expected:

<title>Conformance class A.1: Metadata core (ISO 19115-1)</title>

[Intelligent2013]

Missing row:

<tr>
    <th>
        <bold>Conformance class</bold>
    </th>
    <td>
        <xref ref-type="table" rid="tab_A.20">Conformance class A.2: Metadata extensions and profiles (ISO 19115-1)</xref>
    </td>
</tr>

for

<caption>
       <title>Requirements class 2: Metadata extensions and profiles (ISO 19115-1)</title>
</caption>

[ronaldtse]

I feel that mnconvert should not need to deal with requirements formatting, because the corresponding code is already in metanorma-iso. Is it possible to encode both the semantic xml and the presentational xml together?

Ping @opoudjis

[ronaldtse]

I've discussed with @opoudjis that an output XML that combines semantic + presentational would likely be a reasonable solution. Thoughts?

[Intelligent2013]

I agree that synchronization between metanorma gems changes and mnconvert outputs is a big deal. And you are right that combines semantic + presentation XML will be right solution. I think instead of two XMLs we can have only one generated by two stages:

• semantic XML generation (currently)
• update semantic XML for presentation:
  • add new elements (like pre-rendered table for requirement, pre-rendered xref, eref, etc.), as it made for presentation XML currently,
  • add the attribute semantic='true' for semantic elements, to ignore them on PDF/DOC/HTML rendering

[ronaldtse]

@Intelligent2013 when I discussed with @opoudjis it might be the easiest to have just the presentational and semantic side by side in one XML file, e.g. under <presentation> and <semantic> but the elements can cross-link? @opoudjis is worried that if we go too fine-grained it will be difficult to process for both the generation and processing processes.

[Intelligent2013]

when I discussed with @opoudjis it might be the easiest to have just the presentational and semantic side by side in one XML file, e.g. under <presentation> and <semantic> but the elements can cross-link?

@ronaldtse ok, no problem, I can process such structures.

[opoudjis]

So @ronaldtse Do I have go-ahead to inject the original Semantic XML inside of the Presentation XML, under say /misc-container/semantic-xml?

If I do, I am going to have to change every single anchor in the Semantic XML for disambiguation against the same IDs in the Presentation XML. I will do so by prefixing them all with semantic__.

[ronaldtse]

Do I have go-ahead to inject the original Semantic XML inside of the Presentation XML,

Yes.

under say /misc-container/semantic-xml

I disagree that "misc-container" is a valid element name for what is clearly semantic XML. And there is no reason to repeat the phrase "semantic-xml" within an XML document.

Why not just under /metanorma/semantic or /metanorma/semantics or something like that?

[opoudjis]

I emphatically will not be implementing an open-ended list of container names in Presentation XML. If you don't like misc-container, because counterproductive pedantry, I'll use extension, but all non-presentation content is going to be bundled up in one place.

All sorts of things can still end up under "semantic", but I'll use extension/metanorma/source

[opoudjis]

@Intelligent2013

I am about to globally replace misc-container with metanorma-extension universally in Metanorma. Please update your XSLT accordingly.

I will leave the modifications in PR until you indicate it is done.

[opoudjis]

Decided to make it metanorma-extension, because I'm concerned extension will turn up elsewhere in the XML.

[Intelligent2013]

I will leave the modifications in PR until you indicate it is done.

@opoudjis done.

[opoudjis]

Generating Presentation XML of ISO 19115-3 and sending to @Intelligent2013 to confirm it meets his needs here.

[Intelligent2013]

@opoudjis each element name starts with the prefix semantic__:

<semantic__sections>
            <semantic__clause id="semantic___scope" type="scope" inline-header="false" obligation="normative">
              <semantic__title>Scope</semantic__title>
              <semantic__p id="semantic___d520b2e8-273d-4984-8c15-2ec31b68e477">This document defines an integrated XML implementation of

Just interesting, what is advantage of such approach vs. this xml?

<sections>
            <clause id="semantic___scope" type="scope" inline-header="false" obligation="normative">
              <title>Scope</semantic__title>
              <p id="semantic___d520b2e8-273d-4984-8c15-2ec31b68e477">This document defines an integrated XML implementation of

[opoudjis]

It's to prevent my XPATH queries accidentally hitting semantic XML elements when they should be operating only on presentation XML elements. I can work around this by not prefixing the element names, and just deleting the semantic XML copy before my own processing; but @Intelligent2013 is saying he's ok with this?

[Intelligent2013]

@opoudjis I've found a difference between your presentation+semantic XML with strange text [https___standards.isotc211.org_19115_-1_1_req_metadata-xml_content]:

<xref style="modspec" target="https___standards.isotc211.org_19115_-1_1_req_metadata-xml_content">[https___standards.isotc211.org_19115_-1_1_req_metadata-xml_content]</xref>

and just presentation XML (generated in my environment):

<xref style="modspec" target="rc-19115-1-xml-9" type="inline">Requirements class 14: XML implementation of content information (ISO&#160;19115-1)</xref>

[opoudjis]

Huh. I wonder how that happened. Investigating.

[opoudjis]

Can't confirm, I think it's because I failed to compile with mn-requirements update. I did have to debug the processing of xref targets. Resending, please check.

[Intelligent2013]

It's ok now.

[Intelligent2013]

Done.