Requirements Content Creation for GlassBR

[niazim3]

In order to remove the "code smell" that comes from the use of enumSimple 3 under the Requirements section for GlassBR, as suggested in Monday's meeting, s7_1_req1, s7_1_req2, and s7_1_req6 have to be of [Sentence] type so that enumSimple 1 can be applied to a whole list of requirements. s7_1_req1 has been modified to reference a table that'll appear after the list of requirements (as mentioned in issue #323); s7_1_req2 has been modified so that instead of a nested list (
), a single sentence is produced:
.

Would it be possible to get some suggestions on the best approach to changing s7_1_req6?

@smiths Should s7_1_req6's bulleted list be converted to a table that can be referenced (similar to s7_1_req1)? Compressed into a Sentence (similar to s7_1_req2)?
@szymczdm Or is there a function I am missing to change the type from ItemType -> Sentence? I'm not sure that it would make much sense for an ItemType to be changed to a Sentence type anyhow, which brings the question of perhaps numbering the requirements using a new function that takes in ItemTypes?

[JacquesCarette]

I actually like R6 the way it is. The main thing I would change would be to make the words (like "Actual thickness") be the link -- I despise 'this' links.

[niazim3]

@JacquesCarette If I were to leave it as is, GlassBR will have Enumeration $ Simple $ map ... [acroR 6... in its code, which is a "code smell"... despite that, should it be left as is?

[JacquesCarette]

For now, yes. Once we better understand what we want, we can create the right combinators that make it happen.

[szymczdm]

@JacquesCarette regarding the "this ..." vs. linking the words themselves. Currently that's all handled in the back end, so once I finish updating referencing (milestone 0.1.5; #35 ), we should be able to specify that.

[niazim3]

In that case, this issue can remain open until the decisions are made to remove these "code smell"s, thank you for the input @JacquesCarette.

[smiths]

@niazim3 , you asked me "Should s7_1_req6's bulleted list be converted to a table that can be referenced (similar to s7_1_req1)? Compressed into a Sentence (similar to s7_1_req2)?" When Drasil is complete this kind of decision would be an option that would be given in the recipe for generating the requirements documentation. I don't have a strong preference. If it isn't much additional work, and if it would align better with the other formatting, I do slightly prefer the idea of a table of outputs.

[JacquesCarette]

@smiths is quite right here: the choice between the various format options should be 'trivial' - because the data should exist on its own, and there should be "formatting combinators" for that data, and it should be a matter of just choosing one.

We're not there, but getting extremely close - and that's what we should aim for.

[niazim3]

Since the decision in question is something that will be trivially decided in the future, should this issue be closed?

[JacquesCarette]

No. Because even if we implement the feature (still not fully done), that doesn't mean that the encoding in GlassBR will be such that the feature will be used/enable. That might require a change in GlassBR too. And this issue will remind us of that.

[JacquesCarette]

All of the non-trivial pieces of this are all done. Only the 'future' feature is left. Put a link on the wiki so that this issue can be closed.