Switch to Tables Instead of Lists in GlassBR Func Reqs

[samm82]

The fact that these FRs are represented as lists presents issues for #1403. Would it be acceptable to represent them as labelled lists tables instead, with columns Symbol, Description, Source, and Units?

[smiths]

I'm not sure what you are asking @samm82. When you say labelled list, do you mean a table with a header row at the top? If you are asking whether the requirements can include tables, I see no problem with that. If you are asking something else, I don't know what my opinion is. :-)

[samm82]

Yeah, sorry I meant tables. (my bad) The one potential issue I could see with that is that the tables would be "separated" from the original requirement, as generating them automatically requires passing in the requirements and tables separately, but since it's already being utilized, I think we should be OK. 👍

[smiths]

What is "already being utilized"? Do you mean that the table and the requirement are separated in the Drasil code, or in the generated documentation?

[samm82]

In the above screenshot, the table peeking out from the bottom is the Table:InputsGlassPropsReqInputs referenced in Input-Glass-Props. I thought that having three tables that are "isolated" from the FR they are referenced in might be a little much, so I thought I'd run it by you first.

[smiths]

I'm still not sure I know what you are asking. If you are suggesting we combine the lists from separate requirements into one table, I don't like that idea at all. We want a separation of concerns. If there is a table that lists the inputs, we don't want to confuse things by including non-inputs in the same table.

[samm82]

No, there would be three separate tables, with the following layout and working references:

• FRs 1-6
• Table 1 (from FR1)
• Table 2 (from FR2)
• Table 3 (from FR6)

[smiths]

Hopefully I fully understand what you are proposing, but assuming I do, I like it. The table would actually include the key information; that is, they would contain the information of most interest to the code generator.

[JacquesCarette]

I think he is in part asking about removing the list, because right now there is a weakness in Drasil that doesn't support them in that specific context. Now, it may well be that the information can be re-arranged in a different format that would, in this case, be better. But as a general rule, we shouldn't try too hard to change formatting just because of a weakness in Drasil.

[samm82]

Already changed in #1461