Allow <let/> in <constraint/> without requiring a sibling constraint

[aj-stein-nist]

Committer Notes

Closes #548.

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you squashed any non-relevant commits and commit messages? [instructions]
• Do all automated CI/CD checks pass?

Changes to Core Features:

• Have you added an explanation of what your changes do and why you'd like us to include them? In issue linked to PR.
• Have you written new tests for your core changes, as applicable? Not sure if that is in scope for work item, feedback requested from reviewers.
• Have you included examples of how to use your new feature(s)?
• Have you updated all website](https://pages.nist.gov/metaschema) and readme documentation affected by the changes you made? Changes to the website can be made in the website/content directory of your branch. N/A for this change

[aj-stein-nist]

So I tested the XML Schema by using the merged metaschema module change in #542 (comment) (the source of the issue reported and this PR) with the current XSD file via GH URL in xsi:schemaLocation (a.k.a before) and locally binding to the version in this PR (a.k.a after) and the VS Code XML Schema plugin validation and code completer properly work. See screenshots below.

Before:

After:

I am not sure if we want to include and integrate formal testing into this PR or a related issues for such things moving forward. Let me know.

[aj-stein-nist]

I talked to @david-waltermire for informal review and we need to park this pragmatic and low-effort approach (I can be honest about my work 😄) and discuss different approaches to allow interweaving lets with all the constraint types of having them separate. This could and likely will have implications on backwards compatibility on whether we allow interleaving or keeping them separate.

I am going to work on some examples to move forward discussion in our Element/Gitter chat and in upcoming community discussions.

[aj-stein-nist]

Discussion of this today was postponed, see #548 (comment) for more info. Converting this to draft for now as final reviews are not happening until proper discussion and longer feedback window.

[aj-stein-nist]

I am not sure if this is blocking and/or material to this PR or not.

This is technically out of scope for #548, but given today's conversation, do want to address this concern within this PR and adjust given discussion and around processing order here and now as it has been decided with scope rebinding being disallowed or defer that? Note, the diff on this paragraph is the result of me correcting encounter to encountered to be more grammatical. I think this was the intent.

[wendellpiez]

Ouch, I had a comment here, somehow I dropped it.

Can we codify a rule that no two let element siblings have the same name?

Can we write a constraint for that?

@david-waltermire also grateful for your input here.

[iMichaela]

@wendellpiez - My understanding from the comment above stating that "we need to park this pragmatic and low-effort approach [...] and discuss different approaches to allow interweaving lets with all the constraint types of having them separate. This could and likely will have implications on backwards compatibility on whether we allow interleaving or keeping them separate." is that this PR must be closed.
Can you please provide any background info you might have on this topic?
Thank you

[wendellpiez]

Since OSCAL does not currently use let TMK, this problem will not have any impact on OSCAL until it decides it wishes to do so.

This being the case I think @aj-stein-nist and @david-waltermire might prefer to drive the issue for now (assuming they need it to move) - while in principle I'm amenable to accepting this PR as soon as they say it is done.