Spacing issues in generated Asciidoc

[opoudjis]

Now that I am generating a log of what Lutaml is generating, so I can see the raw Asciidoctor being generated in context, I'm finding several spacing issues that need to be corrected.

Asciidoctor syntax has lots of delimiters of blocks, that need to be preceded and followed (if at the start or end of a block respectively) by an empty line. If this is not done, blocks may not be recognised correctly.

So the following is incorrect:

Sentence.
[example]
====
A
====
B

There needs to be a blank line before the [example], or the ==== if there is no preceding role attribute ([example]), and there needs to be a blank line after the second ====.

In this ticket, I am going to post an example of each such issue that I find in ISO 10303-41.

It may be that some, even most of these, are being parsed correctly anyway. But I don't want to leave it to chance.

[opoudjis]

SVG Map:

.The schemas of this part of ISO 10303
[.svgmap]
====

Blank line before the [.svgmap]

[opoudjis]

Redundant plus?

* the identification of a representation of a property; +
+
[example]
====
A 3D geometric model or a table of numerical values are different representations of properties of a product.
====

The first plus is unnecessary, though likely harmless. The first plus is a <br/>, the second appends the following block to the preceding block (the list item), but it is already understood that there is a break between the two.

[opoudjis]

Example:

The subject of the *action_schema* is the description of actions, the reasons for these actions, and the status of these actions. 
[example]
======
Reasons for action include evolving user requirements, manufacturing problems and difficulties that arise when a product is in use.
======

Blank line before [example]

[opoudjis]

It is not impossible btw that some of these are template issues and not stepmod-utils issues. I'm assigning to @manuelfuenmayor as well to check, but @HassanAkbar should check first.

[opoudjis]

Sending both of you the generated Asciidoc, so you can use it in debugging

[manuelfuenmayor]

This is markup error from action_schema.exp.

SVG Map:

.The schemas of this part of ISO 10303
[.svgmap]
====

Blank line before the [.svgmap]

@opoudjis, .The schemas of this part of ISO 10303 is just the caption of the svgmap. Are you sure a blank line should go in between?

[manuelfuenmayor]

The schemas of this part of ISO 10303

Redundant plus?

* the identification of a representation of a property; +
+
[example]
====
A 3D geometric model or a table of numerical values are different representations of properties of a product.
====

The first plus is unnecessary, though likely harmless. The first plus is a <br/>, the second appends the following block to the preceding block (the list item), but it is already understood that there is a break between the two.

This is a markup issue. I'll fix it.

[manuelfuenmayor]

Example:

The subject of the *action_schema* is the description of actions, the reasons for these actions, and the status of these actions. 
[example]
======
Reasons for action include evolving user requirements, manufacturing problems and difficulties that arise when a product is in use.
======

Blank line before [example]

This is also a markup issue from action_schema.exp. Fixing.

[TRThurman]

Now that I am generating a log of what Lutaml is generating, so I can see the raw Asciidoctor being generated in context, I'm finding several spacing issues that need to be corrected.

Asciidoctor syntax has lots of delimiters of blocks, that need to be preceded and followed (if at the start or end of a block respectively) by an empty line. If this is not done, blocks may not be recognised correctly.

So the following is incorrect:

Sentence.
[example]
====
A
====
B

There needs to be a blank line before the [example], or the ==== if there is no preceding role attribute ([example]), and there needs to be a blank line after the second ====.

In this ticket, I am going to post an example of each such issue that I find in ISO 10303-41.

It may be that some, even most of these, are being parsed correctly anyway. But I don't want to leave it to chance.

@opoudjis, @ronaldtse, a annotated EXPRESS syntax checker is planned for the easyEXPRESS visual studio code plug in but not till later. Hopefully that plug-in will be available early next year. I expect an initial checker would run as a pre-commit check. I leave it to you folks to decider where that issue should be applied in this github environment.

[opoudjis]

@manuelfuenmayor I defer to you.

Nothing is jumping out in the generated 42, but I retain the right to reopen this later...