[yfanti]

No description provided.

[yfanti]

@pdonohoe @YvesJo please check the manual change in Schematrons and if its ok re-approve, since I have added the Changelog commit and your approval has been dismissed.

[yfanti]

Label resolution for the stage-1m rules — investigated

While verifying rc.2 I checked whether the rule-message labels referenced by the
Schematron files actually resolve in the exported translations. Summary: the
generated SDK is internally consistent, but the 24 manually maintained stage-1m
rules reference labels that are not exported.

The generated content is fine. All 30,673 rule|text|… references used by the
generated static schematrons resolve in translations/. Zero unresolved.

65 rule|text labels exist in the MDD with usage of sdk1/all but are not
exported. They fall into two groups:

41 are orphans from renamed or removed rules — BR-BT-00040-0012,
BR-BT-00050-0101..0104, BR-BT-00070-*, BR-BT-00088-*, BR-BT-00105-0110..0112,
BR-BT-00137-0204/0216/0217, BR-BT-00539-*, BR-BT-01311-0150/0151 and others. No
exported rule references them, so omitting them is correct. These are simply leftover
labels whose rules have since been renamed.

24 are the stage-1m set — BR-BT-00191-0053, BR-BT-00556-0102, BR-BT-00651-0055,
BR-BT-13713-0180, BR-OPT-00200-0104 and the rest. Mechanically the exporter treats
them the same way: these rules exist only in the hand-written
validation-stage-1m.sch plus their rule_to_notice records, never in the generated
rule set, so their labels look unused and are omitted.

Consequence: those 24 messages will not resolve for a consumer of the SDK. This is
not a regression — rc.1 had the same gap, just pointing at the SDK 2 ids (R-*),
which are usage=sdk2 and therefore also absent from the SDK 1 translations. The new
static file is strictly better, because the ids are now the SDK 1 ones and consistent
with the MDD.

It is also not something the analyser catches: it verifies that every assert has a
<diagnostic> definition, which they all do, but not that a message's label reference
exists in the translations.

Question for @YvesJo and @pdonohoe: should the translations export include labels
for rules registered only via rule_to_notice? Until it does, these messages stay
unresolvable, and since this stage is only testable through eNotices2 it may not
surface in normal testing.

One related observation: static/validation-stage-1m.sch now references the SDK 1 ids
while dynamic/validation-stage-1m.sch still references the SDK 2 ids, following the
"RC2 static folder only" instruction. So the same rule reports under a different label
id depending on which variant is used. Worth confirming that the dynamic folder is
deliberately deferred rather than overlooked.