How to deal with conditionalities that are not (currently) framed as profile options
@ToddCooper is already working on this.
Since Oct 31, 2025.
- Dominant language
- Kotlin
- Stars
- 17
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Description
How do / should we deal with conditionality other than as formal profile options (e.g., is it possible to have conditional text in requirement statements + a "conditional" hidden label?). If we have only profile options we may see an explosive proliferation of those!
Here is the concrete example that triggered these questions, coming from the review of PR#469, and moved from there to this new issue to unlock progress on PR#469:
R0800, R0801and R0802 are shall level requirements that, accordingly, show up as "r" in the ICS table 3:Z.2.2-1 for SOMDS Providers. Shouldn't that be conditional on (1) the Participant using the sdpi:ReportSequence extension (which is "should" in all 2:A.5.2 requirements) AND (2) the Participant using MDPWS (as that extension is defined in 2:A)?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.