Keep track of all projects using lutaml-model

[ronaldtse]

Using:

• https://github.com/lutaml/genericode
• https://github.com/lutaml/ogc-gml
• https://github.com/metanorma/modspec-ruby
• https://github.com/metanorma/rfcxml
• https://github.com/metanorma/niso-jats
• https://github.com/metanorma/sts-ruby
• https://github.com/lutaml/metaschema
• https://github.com/glossarist/termium
• https://github.com/lutaml/oasis-etm
• https://github.com/lutaml/ali
• https://github.com/lutaml/reqif

In migration:

• [WIP] Migrate to lutaml-model xmi#49
• Utilize OSCAL "metaschema" for parsing OSCAL oscal#18
• MathML parsing using LutaML-Model plurimath/mml#2
• port Shale to Lutaml::Model: https://github.com/metanorma/metanorma/i… metanorma/metanorma#403

Pending migration:

• https://github.com/plurimath/omml
• Change Glossarist gem to use lutaml-model glossarist/glossarist-ruby#107

[ronaldtse]

@HassanAkbar this is so that we know what gems we can test against to know if the latest versions of lutaml-model are backwards compatible (i.e. will any user break).

[ronaldtse]

@CAMOBAP a recent update of lutaml-model broke some of the gems. We wish to add an automated workflow that runs the tests of some external gems that we manage, such as:

simple ones:

• ogc-gml
• genericode

complex ones:

• sts-ruby
• xmi

Can we make those part of the build process (as separate jobs)? i.e. we checkout those repositories, run their specs against our local code of lutaml-model.

[opoudjis]

This will eventually include metanorma and modspec-ruby. But not until the integration issues for them are debugged and confirmed.

[CAMOBAP]

For now, we have two approaches for testing which are 'flavor'-based in relaton-index and pubid-core:

• https://github.com/relaton/relaton-index/blob/main/.github/workflows/dependent-tests.yml
• https://github.com/metanorma/pubid-core/blob/main/.github/workflows/dependent-tests.yml

It makes sense to make a more general approach to list repo name instead flavor and reuse it in this repo + relaton-index, pubid-core too