Skip to content

Automatically collect abbreviations from generated DocDescs#4363

Open
sarrasoussia wants to merge 66 commits intomainfrom
tableAccAbbS
Open

Automatically collect abbreviations from generated DocDescs#4363
sarrasoussia wants to merge 66 commits intomainfrom
tableAccAbbS

Conversation

@sarrasoussia
Copy link
Collaborator

@sarrasoussia sarrasoussia commented Sep 7, 2025

Closes #4299
Based on #4323

Builds on #4695

@sarrasoussia

This comment was marked as outdated.

@balacij

This comment was marked as outdated.

@sarrasoussia

This comment was marked as outdated.

balacij

This comment was marked as outdated.

JacquesCarette

This comment was marked as outdated.

@balacij

This comment was marked as outdated.

"|DD|Data Definition|\n",
"|GD|General Definition|\n",
"|GS|Goal Statement|\n",
"|GamePhysics|GamePhysics|\n",
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think GamePhysics should be treated as an abbreviation.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

progName :: CI
progName = commonIdeaWithDict "gamePhysics" (pn "GamePhysics") "GamePhysics" [physics]

GamePhysics (and the other examples you mentioned) all have code like this above because we require each of our case studies to have an abbreviation/codename.

So, should we loosen said restriction and remove the false abbreviation given to GamePhysics and co.? Or should we write a rule that filters out abbreviations in the table if they're equivalent to the terms. Or something else entirely?

Or should we write a rule that filters out abbreviations in the table if they're equivalent to the terms.

This might be a good rule to impose on our IdeaDicts, CIs, etc. in general.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An abbreviation is not a a 'codename'. If we require codenames, we should have a different data-structure for those.

We should not conflate different concepts.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Going back to this, while I agree with you, I think this is out of scope for this PR. We should fix it in another. I'm okay with this PR being blocked on that, but I'm also okay with pushing it to later in the name of merging in this PR (which is already quite large and a bit difficult to keep up to date with main).

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good: I think we should indeed fix that first.

I'm thinking a new ProgramName chunk, with fields name (or label) and some optional description. It should not implement the term lens. We're overloading CI too far here.

"<a id=\"Sec:LCs\"></a>\n",
"\n",
"This section lists the likely changes to be made to the software.\n",
"This section lists the Likely Changes (LC) to be made to the software.\n",
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

likely changes should not be capitalized here (same with Unlikely Changes below)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we not always want to capitalize noun phrases when we introduce their acronyms?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so - but we should ask @smiths for another opinion.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have always thought that capitalization should be used for introducing acronyms, but I recently learned that the rule is to capitalize the words in expanded form if the full phrase is a proper name or a formal title, like NASA. If the expanded phrase is not a proper noun, then the individual words are not capitalized, like research software engineer (RSE). According to ChatGPT, the APA, AMA, Chicago and IEEE all say this.

Do we have any way of knowing in our Drasil data whether the expanded form of our acronyms is a proper noun or not?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In theory, we have a way of knowing whether something is a proper noun or not. In practice, it has been abused, so it is not currently a proper source of 'truth'. But we could make it so.

Thanks for justifying that the individual words should not be capitalized.

Copy link
Collaborator

@balacij balacij Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @smiths!

Resolved in b76a720

Added PR #4695 as a dependency here too.

<td>Glass Type Factor</td>
</tr>
<tr>
<td>GlassBR</td>
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, GlassBR should not be treated as an abbreviation.

<td>proportional derivative</td>
</tr>
<tr>
<td>PD Controller</td>
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same "PD Controller" should not be an abbreviation

<td>Physical System Description</td>
</tr>
<tr>
<td>Projectile</td>
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Projectile should not be an abbreviation

"|Refname|Reference Name|\n",
"|SRS|Software Requirements Specification|\n",
"|SWHS|Solar Water Heating System|\n",
"|SWHS|Solar Water Heating Systems Incorporating PCM|\n",
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SWHS now has two meanings!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, but, similarly, I think this is out of scope for this PR. We will need to file an issue if this PR is approved+merged.

balacij added a commit that referenced this pull request Jan 28, 2026
@balacij
Copy link
Collaborator

balacij commented Jan 28, 2026

I think I'm going to call this PR "Ready for Review," @JacquesCarette @smiths. Regarding the paragraph previously added through this PR, as I mentioned in #4363 (comment), I've removed it. We should fix the root issue here in a subsequent PR. For now, I think this PR is fine enough.

There is the issue of the "code name"s being added to the table of abbreviations and acronyms, but I think we can file an issue to deal with this later.

Copy link
Collaborator

@smiths smiths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked at the changes to stable. The changes look reasonable to me.

@JacquesCarette
Copy link
Owner

There's a conflict to resolve.

mkSections si dd = map doit dd
mkSections si dd =
let
splitByTAandA :: [[DocSection]]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this code should be refactored into even more generic kit. What you are doing is creating a 'view' (in this case, zooming in to RefSec), mapping onto one side of that view, and then putting everything back together.

A more refined way to do this would take a function (a -> Either b c) instead of a predicate, then two functions (b -> d) and (c -> d) for each side, then you could unEither. In the case below, it would actually be (a -> Either b a) and the function on the False stuff would be id.

@@ -126,10 +126,10 @@ sentencePlate f = appendPlate (secConPlate (f . concatMap getCon') $ f . concatM
(GDs s _ d _) -> def d ++ s ++ der d ++ notes d
(IMs s _ d _) -> s ++ der d ++ notes d
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this part is still not addressed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Automatically collect abbreviations for SRS

4 participants