As a follow up to:

• metanorma/metanorma-iso#777 (comment)
• metanorma/metanorma-iso#789

We need to update:

• Only "Normative statement" instances (requirement, recommendation, permission) should use statement ("Statement") because the statement is the content to comply against. There is no description (remains a synonym) in a "Normative statement"
• Conformance tests do not use statement, only description, because the content serves as informative description of the conformance test.
• Requirements classes, Conformance classes do not use statement, only description, because the content serves as informative description of the classes.

This change is needed for:

• metanorma/metanorma.org#677

The definition list syntax for Modspec allows requirements, permissions, recommendations to be entered as children of provisions, but none of the other classes of provisions, such as conformance tests as children of conformance classes. Such children can be notated through nested open blocks, but succinct marking is preferable. So I will allow conformance-test conformance-class abstract-test requirement-class recommendation-class permission-class as definition list tags openly, rather than impose constraints.

• A requirement must at least have a conformance test
• A requirements class must at least have a conformance class
• A requirements class must at least have a requirement
• A conformance test must link to one requirement
• A conformance test must belong to a conformance class
• A conformance class must contain more than one conformance test

This is to be ported from metanorma-ogc.

I've started using tags instead of rake release to push out versions of gems. I've manually pushed mn-requirements to rubygems, since neither 0.0.3 nor 0.1.0 was pushed (the former 5 days ago). Could I confirm that tagging is set up to publish mn-requirements ?

Relating to metanorma/metanorma-standoc#692

ISO 19115-3 has seen fit to introduce a notion of identifier base, and to allow the identifier base to be stripped as a prefix from instances of identifiers within scope of that base. An identifier base can be defined at document level (with a document attribute :modspec-identifier-base:), and in a requirement; it is inherited by any requirements that are in a class-member relation with the defining requirement. The scope of the identifier base is all identifiers used within that requirement.

The identifier base of a requirement (or requirement class) shall be indicated with the dl tag identifier-base.

Therefore, given

:modspec-identifier-base: http://www.example.com

[[id1]]
[requirements_class]
----
identifier-base:: http://www.example.com/modspec/griffin
identifier:: http://www.example.com/modspec/griffin/reqt/3
----

[[id11]]
[requirement]
----
identifier:: http://www.example.com/modspec/griffin/reqt/3/reqt/1
description See also xref:http://www.example.com/modspec/griffin/reqt/3/reqt/5[style=id%] and xref:http://www.example.com/modspec/griffin/reqt/4/reqt/7[style=id%]
----

Refer to xref:http://www.example.com/modspec/griffin/reqt/3/reqt/1[style=id%]

Will render as

Requirements class 1
Identifier: http://www.example.com/modspec/griffin/reqt/3

Requirement 1
Identifier: http://www.example.com/modspec/griffin/reqt/3/reqt/1
Statement: See also reqt/5 and http://www.example.com/modspec/griffin/reqt/4/reqt/7

Refer to modspec/griffin/reqt/3/reqt/1

In a requirements class "Provisions" contain multiple provisions.

However, in a requirement, "Dependency" is each shown on individual rows.

Can we apply the same treatment across both, i.e. if there are multiple, keep them together?

I am trying to remove a circular dependency of isodoc on isodoc-i18n:

isodoc depends on mn-requirements
mn-requirements depends on isodoc-i18n
isodoc depends on isodoc-i18n
mn-requirements depends on isodoc (development only)

I am removing the dependency of isodoc on isodoc-i18n tomorrow, and I'm trying to release mn-requirements today; but bundle install + the development dependency on mn-requirements are preventing me from running release.

I understand that we are releasing bundle install from all release tasks, in order to deal with this kind of circularity?

Notice the "Dependency" rows are not rendered as requirements because they are indeed missing. Metanorma needs to display warning messages if these requirements are not found.

In this requirements class, "Conformance test", "Provisions" both show "requirements cross-references".

However, "Implements" is also referring to a requirement but it is not rendered as such. Can we have a syntax that does that?

As suggested by the ISO/TC 211 EPM, the table headings in the left column can be rendered in bold for clarity.

In the current ISO 19115-3 there are multiple circular dependencies, which means that implementation of them cannot be possible.

This means that we need to detect these circular loops and alert the authors to think hard and break them.

The following questions should be addressed:

1. How do I specify a new data model for requirements? (e.g. ISO's version)
2. How do I enter instances for that data model? (presumably simplest using YAML/hash and provide a defined mapping from MN Adoc to YAML/hash)
3. How do I specify the rendering of a model into Presentation XML (e.g. into a table) (presumably liquid)

https://github.com/metanorma/iso-19135 should be used as an example for this work.