Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate mn-requirements with modspec-ruby #30

Open
opoudjis opened this issue Jul 30, 2024 · 4 comments
Open

Integrate mn-requirements with modspec-ruby #30

opoudjis opened this issue Jul 30, 2024 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@opoudjis
Copy link
Contributor

https://github.com/metanorma/modspec-ruby

@opoudjis opoudjis added the enhancement New feature or request label Jul 30, 2024
@opoudjis opoudjis self-assigned this Jul 30, 2024
@opoudjis
Copy link
Contributor Author

opoudjis commented Aug 9, 2024

I'm not integrating an undocumented and untested gem. Without metanorma/modspec-ruby#4 done, I'm not touching this.

@opoudjis
Copy link
Contributor Author

The requirement given by Ronald is that serialisation be done of the object model in modspec-ruby, via lutaml-model, rather than proceed through the normal to date avenue of parsing Asciidoc to generate Ruby.

This is counter to the way all processing of external objects has been done to date, which is as Asciidoc preprocessing, with Asciidoc as the target format, guaranteeing a single consistent source of information for the document, processed in only one workflow.

Metanorma processes Asciidoctor in two stages: an initial generation of XML, and a cleanup step.

There will be things that the Metanorma initial processing stage does in generating XML, that will need to be redone independently in serialising through lutaml-model; for example, the default values and processing of anchor attributes. The serialisation "out of the box" of an arbitrary document model is also going to be nothing like what Metanorma expects of its XML, and will need a custom serialisation.

In other words, the lutaml-model-solves-everything model of Asciidoctor which is increasingly being advocated for by Ronald is going to introduce duplication and maintenance burden on the Asciidoc processing model. (Leave alone the manifest immaturity of lutaml-model for serialising anything more complex than a hash of strings.)

The request by OGC to process Modspec YAML inline means that at this time, I am going to handle Modspec YAML processing both of external and of inline file instances in the same way. The signal to Metanorma that the requirement content is encoded as YAML, and not as an Asciidoc definition list, shall be a requirement wrapping a block of YAML sourcecode:

[requirement]
====
[source,yaml]
----
identifier: /req/relief/classes
statement: "For each UML class defined or referenced in the Relief Package:"
parts:
- The Implementation Specification SHALL contain an element which represents the
same concept as that defined for the UML class.
- The Implementation Specification SHALL represent associations with the same
source, target, direction, roles, and multiplicities as those of the UML class.
----
====
[requirement]
====
[source,yaml]
----
include::1.yaml[]
----
====

There is no particular need for a distinct macro to import Modspec YAML, it would only replicate 6 lines of the same wrapper around the imported YAML.

@opoudjis
Copy link
Contributor Author

On hold pending lutaml/lutaml-model#82

@opoudjis
Copy link
Contributor Author

opoudjis commented Sep 15, 2024

On hold pending lutaml/lutaml-model#88

Apart from that, there is going to be Asciidoc markup in the YAML files, which under this serialisation will need to be converted to Metanorma XML:

      description: |
        To confirm that the `Regular_Series.interPoseDuration` attribute is
        represented by an instance of the `GeoPose_Duration` object.

I don't have any indication that such conversion is supported by coradoc yet, so I will need to port the adoc2xml method (which parses a standoc document with Asciidoc markup, to make it available as Metanorma XML) to metanorma-utils, until coradoc does generate Metanorma XML.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: On hold
Development

No branches or pull requests

1 participant