Restore 4 uniqueness removed in #998 where no xsd:key covers it (+ must-fail guards) by thbar · Pull Request #1032 · TransmodelEcosystem/NeTEx

thbar · 2026-06-20T14:31:46Z

Scope of this PR

To be merged into Remove unique constraints, because we have xsd:key #998 ("Remove unique constraints, because we have xsd:key").
Undoes 4 of Remove unique constraints, because we have xsd:key #998's removals — the cases where no xsd:key enforces the uniqueness: GroupOfLinkSequences, OperatingDay, ValidBetween and ValidityPeriod.
Adds must-fail examples (examples/should-fail/) that prove the uniqueness is no longer enforced — we can decide later what to do with them (e.g. keep them as permanent CI guards).

This PR restores the missing xsd:unique — otherwise v2.0.1 would not be a correct optimisation, since it would silently drop validation that v2.0.0 had (these four were enforced in v2.0.0 via xsd:unique).

It does not replace them with xsd:key. For GroupOfLinkSequences, afaik xsd:key was there before v2.0.0, but has removed by #721/#462 before v2.0.0 was released (which is why it's important to avoid also removing unique here).

Whether to (re)introduce keys is a separate discussion we can have, but not the scope of this PR (and maybe not for a v2.0.1 bug fix either).

(revert of 51b79ea for this constraint)

skinkie · 2026-06-20T15:01:20Z

 		</xsd:key>
 		<!-- =====GroupOfLinkSequences============================== -->
+		<!-- =====GroupOfLinkSequences unique========================== -->
+		<xsd:unique name="GroupOfLinkSequences_UniqueBy_Id_Version">


Why do you think this is correct? For example, why isn't this just a key?

See PR description (just added) ; I think it's more correct that what is in #998 on that specific bit, which was effectively removal of any sort of uniqueness check.

Why not key, well, key has been removed before v2.0.0 (see description). I don't know if adding it back in a patch release is a good idea or not, we'll have to discuss that collectively.

@thbar and @skinkie,
I confirm that in v1.3, this part was written as follow:

  <xsd:unique name="GroupOfLinkSequences_UniqueBy_Id_Version"> <xsd:annotation> <xsd:documentation>Every [GroupOfLinkSequences Id + Version] must be unique within document.</xsd:documentation> </xsd:annotation> <xsd:selector xpath=".//netex:GroupOfLinkSequences"/> <xsd:field xpath="@id"/> <xsd:field xpath="@version"/> </xsd:unique>

Direct link is this one.

Considering that GroupOfLinkSequencesRef is based on the substitution group VersionOfObjectRef and not TypeOfEntityRef, I am uncertain that a key will work.

However, let's make it simple and roll back to the original state of this part of the XSD.

Also, assert that the file cannot be considered valid, first and foremost.

ValidBetween lost (afaik) id+version uniqueness in 51b79ea and no xsd:key covers it (guarded by examples/should-fail/duplicate-ValidBetween.xml). Exact verbatim revert, byte-identical to v2.0. Its selector also covers ValidityCondition/ValidityTrigger/ValidityRuleParameter, which keys already cover - kept verbatim to stay an exact revert, not trimmed (but this can be covered by a later optimisation).

ValidityPeriod lost id+version uniqueness in 51b79ea and no xsd:key covers it (guarded by examples/should-fail/duplicate-ValidityPeriod.xml). Should be verbatim revert (compared to v2.0). Its selector also covers UsageValidityPeriod, which a key already covers - kept verbatim to stay an exact revert, not trimmed.

skinkie · 2026-06-20T18:46:39Z

 		</xsd:key>
 		<!-- ===== UsageValidityPeriod Key ========================== -->
+		<!-- ===== UsageValidityPeriodting unique========================== -->
+		<xsd:unique name="UsageValidityPeriod">


It should be unique by key.

See PR description, I'm just undoing problematic removal of any uniqueness at all, this is not a PR where I'm changing any unique to a key (and as commented above, at least one was removed just pre-v2.0.0, so it would be a bit confusing).

To be discussed, then (but this is not this PR's goal).

A duplicate id is never correct, it is a key. Hence it should not be unique.

See #1032 (comment)

Indeed, UsageValidityPeriod has both unique and key checked. So, the stand-alone key can remain.

XSD v1.3:

  <xsd:unique name="UsageValidityPeriod"> <xsd:annotation> <xsd:documentation>Every [UsageValidityPeriod Id + Version] must be unique within document.</xsd:documentation> </xsd:annotation> <xsd:selector xpath=".//netex:UsageValidityPeriod | .//netex:ValidityPeriod"/> <xsd:field xpath="@id"/> <xsd:field xpath="@version"/> </xsd:unique> <xsd:keyref name="UsageValidityPeriod_KeyRef" refer="netex:UsageValidityPeriod_AnyVersionedKey"> <xsd:selector xpath=".//netex:UsageValidityPeriodRef"/> <xsd:field xpath="@ref"/> <xsd:field xpath="@version"/> </xsd:keyref> <xsd:key name="UsageValidityPeriod_AnyVersionedKey"> <xsd:selector xpath=".//netex:UsageValidityPeriod"/> <xsd:field xpath="@id"/> <xsd:field xpath="@version"/> </xsd:key>

Permalink to the XSD

skinkie · 2026-06-20T18:47:04Z

@thbar read the comments.

…cript

thbar · 2026-06-22T15:09:05Z

@thbar read the comments.

I got notified by your other comments, no problem. Now the PR is ready to review.

Hopefully we can merge & we didn't miss any other similar issues, so that #998 can go ahead.

skinkie · 2026-06-22T15:21:40Z

 		</xsd:key>
 		<!-- =====ValidityCondition============================== -->
+		<!-- =====ValidityCondition unique========================== -->
+		<xsd:unique name="ValidityCondition_UniqueBy_Id_Version">


Should just be a key.

This is worth a dedicated ticket (for this one & all the places deserving a key, either removed erroneously before v2.0.0 or not), and its own separate PR(s).

#1032 is just short rollback of 4 missing uniques.

I think the opposite is true. It was erronousley added as unique, and the removal script removed id unique, because the expectation was a key must exist for an id.

Yes, yet the key isn't there, so it creates a larger trouble even (no more unicity at all). We'll need to address that, so I created #1034 ; we'll catalogue over there.

@thbar and @skinkie,
ValidityCondition has both the unique and key checked. So we can omit this roll-back.

XSD from v1.3 is as follow

 <xsd:unique name="ValidityCondition_UniqueBy_Id_Version"> <xsd:annotation> <xsd:documentation>Every [ValidityCondition Id + Version] must be unique within document.</xsd:documentation> </xsd:annotation> <xsd:selector xpath=".//netex:ValidityCondition | .//netex:ValidityTrigger | .//netex:ValidityRuleParameter | .//netex:ValidBetween"/> <xsd:field xpath="@id"/> <xsd:field xpath="@version"/> </xsd:unique>  <xsd:keyref name="ValidityCondition_KeyRef" refer="netex:ValidityCondition_AnyVersionedKey"> <xsd:selector xpath=".//netex:ValidityConditionRef | .//netex:ValidityTriggerRef | .//netex:ValidityRuleParameterRef | .//netex:WithConditionRef"/> <xsd:field xpath="@ref"/> <xsd:field xpath="@version"/> </xsd:keyref> <xsd:key name="ValidityCondition_AnyVersionedKey"> <xsd:selector xpath=".//netex:ValidityCondition | .//netex:ValidityTrigger | .//netex:ValidityRuleParameter | .//netex:AvailabilityCondition"/> <xsd:field xpath="@id"/> <xsd:field xpath="@version"/> </xsd:key>

This is the permalink.

TuThoThai

@thbar, I believe that the only roll-back needed is on GroupOfLinkSequences since we have key checked for the other 3.

Could you please double-check using your examples? 🙏

TuThoThai · 2026-07-22T13:33:46Z

 		</xsd:key>
 		<!-- =====GroupOfLinkSequences============================== -->
+		<!-- =====GroupOfLinkSequences unique========================== -->
+		<xsd:unique name="GroupOfLinkSequences_UniqueBy_Id_Version">


@thbar and @skinkie,
I confirm that in v1.3, this part was written as follow:

  <xsd:unique name="GroupOfLinkSequences_UniqueBy_Id_Version"> <xsd:annotation> <xsd:documentation>Every [GroupOfLinkSequences Id + Version] must be unique within document.</xsd:documentation> </xsd:annotation> <xsd:selector xpath=".//netex:GroupOfLinkSequences"/> <xsd:field xpath="@id"/> <xsd:field xpath="@version"/> </xsd:unique>

Direct link is this one.

Considering that GroupOfLinkSequencesRef is based on the substitution group VersionOfObjectRef and not TypeOfEntityRef, I am uncertain that a key will work.

However, let's make it simple and roll back to the original state of this part of the XSD.

TuThoThai · 2026-07-22T13:36:37Z

 		</xsd:key>
 		<!-- =====ValidityCondition============================== -->
+		<!-- =====ValidityCondition unique========================== -->
+		<xsd:unique name="ValidityCondition_UniqueBy_Id_Version">


@thbar and @skinkie,
ValidityCondition has both the unique and key checked. So we can omit this roll-back.

XSD from v1.3 is as follow

 <xsd:unique name="ValidityCondition_UniqueBy_Id_Version"> <xsd:annotation> <xsd:documentation>Every [ValidityCondition Id + Version] must be unique within document.</xsd:documentation> </xsd:annotation> <xsd:selector xpath=".//netex:ValidityCondition | .//netex:ValidityTrigger | .//netex:ValidityRuleParameter | .//netex:ValidBetween"/> <xsd:field xpath="@id"/> <xsd:field xpath="@version"/> </xsd:unique>  <xsd:keyref name="ValidityCondition_KeyRef" refer="netex:ValidityCondition_AnyVersionedKey"> <xsd:selector xpath=".//netex:ValidityConditionRef | .//netex:ValidityTriggerRef | .//netex:ValidityRuleParameterRef | .//netex:WithConditionRef"/> <xsd:field xpath="@ref"/> <xsd:field xpath="@version"/> </xsd:keyref> <xsd:key name="ValidityCondition_AnyVersionedKey"> <xsd:selector xpath=".//netex:ValidityCondition | .//netex:ValidityTrigger | .//netex:ValidityRuleParameter | .//netex:AvailabilityCondition"/> <xsd:field xpath="@id"/> <xsd:field xpath="@version"/> </xsd:key>

This is the permalink.

TuThoThai · 2026-07-22T13:39:25Z

 		</xsd:key>
 		<!-- ===== UsageValidityPeriod Key ========================== -->
+		<!-- ===== UsageValidityPeriodting unique========================== -->
+		<xsd:unique name="UsageValidityPeriod">


Indeed, UsageValidityPeriod has both unique and key checked. So, the stand-alone key can remain.

XSD v1.3:

  <xsd:unique name="UsageValidityPeriod"> <xsd:annotation> <xsd:documentation>Every [UsageValidityPeriod Id + Version] must be unique within document.</xsd:documentation> </xsd:annotation> <xsd:selector xpath=".//netex:UsageValidityPeriod | .//netex:ValidityPeriod"/> <xsd:field xpath="@id"/> <xsd:field xpath="@version"/> </xsd:unique> <xsd:keyref name="UsageValidityPeriod_KeyRef" refer="netex:UsageValidityPeriod_AnyVersionedKey"> <xsd:selector xpath=".//netex:UsageValidityPeriodRef"/> <xsd:field xpath="@ref"/> <xsd:field xpath="@version"/> </xsd:keyref> <xsd:key name="UsageValidityPeriod_AnyVersionedKey"> <xsd:selector xpath=".//netex:UsageValidityPeriod"/> <xsd:field xpath="@id"/> <xsd:field xpath="@version"/> </xsd:key>

Permalink to the XSD

thbar added 5 commits June 20, 2026 16:14

Add reproduction for uniqueness regression

05f525b

Add quick readme on should-fail folder

23a70f1

Create minimalistic "should fail" harness on CI

4ae5c3b

Merge branch 'v2_remove_unique' into v2_remove_unique_regression_fix

cc4327e

Restore GroupOfLinkSequences uniqueness

a2bc91f

(revert of 51b79ea for this constraint)

skinkie reviewed Jun 20, 2026

View reviewed changes

thbar and others added 8 commits June 20, 2026 18:12

Make "should-fail" checks assert behaviour, not the constraint name

6b77671

Also, assert that the file cannot be considered valid, first and foremost.

Add failing example for duplicate "OperatingDay by CalendarDate"

4d8f7d0

We do not want duplicate ValidBetween (same id + version)

7c8f516

Add test-case for duplicate ValidityPeriod

0884659

Restore OperatingDay CalendarDate uniqueness

6819d84

Lint and update documentation tables

70f4d93

skinkie reviewed Jun 20, 2026

View reviewed changes

Batch verifications (much shorter time) like for regular validation s…

430e8af

…cript

thbar changed the title ~~[WIP] Regression fixes for #998~~ Restore 4 uniqueness removed in #998 where no xsd:key covers it (+ must-fail guards) Jun 22, 2026

thbar marked this pull request as ready for review June 22, 2026 15:03

thbar mentioned this pull request Jun 22, 2026

Remove unique constraints, because we have xsd:key #998

Open

skinkie reviewed Jun 22, 2026

View reviewed changes

thbar mentioned this pull request Jun 22, 2026

Places that would need an xsd:key #1034

Open

TuThoThai added this to the netex_2.0 milestone Jun 23, 2026

ue71603 self-requested a review July 7, 2026 14:53

TuThoThai self-requested a review July 19, 2026 14:22

TuThoThai requested changes Jul 22, 2026

View reviewed changes

TuThoThai requested a review from skinkie July 22, 2026 13:43

Uh oh!

Conversation

thbar commented Jun 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

skinkie commented Jun 20, 2026

Uh oh!

thbar commented Jun 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TuThoThai left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

thbar commented Jun 20, 2026 •

edited

Loading