Remove unique constraints, because we have xsd:key

[skinkie]

Fix #994

With unique constraints:

real	4m5.527s
user	3m57.850s
sys	0m1.706s

Without unique constraints:

real	2m44.075s
user	2m39.062s
sys	0m1.093s

[TuThoThai]

@skinkie,
Considering it is not a bug fix, only a redundance, would you prefer to it to be release with 2.0.1 or 2.1? In the latter case, we only change the target branch.
🙏

[skinkie]

2.0.1

[thbar]

I had a first look locally today; the branch is not up-to-date anymore, so I'll push the "update from v2.0" from my machine. @TuThoThai in order for GitHub to detect that a branch is not up-to-date, we'll have to (re?)-enable "check status updates" first.

[TuThoThai]

@skinkie, great work on this one! It definitly helped a lot with the validation speed, but also made the Schema much faster to load with tools like XMLSpy

I made a tiny commit to:

• add your work on ref / constraints in the metadata
• changed the status to 2.0

[thbar]

I did manual + automated (AI) reviews. The vast majority (> 97%) of the stuff seems right to me. I have questions on a few remaining cases.

Can someone with more historical or functional context comment on these? (@skinkie and others!).

Unsure at this point if these are false positives / issues with the review, or something that deserves actual changes possibly.

Potentially (???) missing xsd:key Replacements

• AlternativeName_UniqueBy_Id_Version_useForLanguage_ordered - Alternative names with language/order constraint
• AlternativeText_UniqueBy_Id_AttributeName_UseForLanguage_Version - Alternative text with 4-field uniqueness (@id, @attributeName, @useForLanguage, @version)
• Vehicle_UniqueRegistrationNumber - Vehicle registration number uniqueness constraint
• Call_UniqueBy_Id_Version_Order - Call element uniqueness with ordering
• DynamicDistanceMatrixElement_UniqueBy_Id_Version - Dynamic distance matrix element constraint

[thbar]

And a quick performance test. It looks on this specific test we're back to v1.3.1 performance level. Nice work @skinkie, thanks for tackling this out.

❯ elixir compare.exs
xmllint --noout --schema NeTEx-v1.3.1/xsd/NeTEx_publication.xsd data/fr-nap-idfm.zip.unpack/arrets.xml 2>&1
NeTEx-v1.3.1 took 99.970771 seconds
xmllint --noout --schema NeTEx-v2.0.0/xsd/NeTEx_publication.xsd data/fr-nap-idfm.zip.unpack/arrets.xml 2>&1
NeTEx-v2.0.0 took 127.551984 seconds
xmllint --noout --schema NeTEx-v2_remove_unique/xsd/NeTEx_publication.xsd data/fr-nap-idfm.zip.unpack/arrets.xml 2>&1
NeTEx-v2_remove_unique took 100.858296 seconds

[Aurige]

I did manual + automated (AI) reviews. The vast majority (> 97%) of the stuff seems right to me. I have questions on a few remaining cases.

Can someone with more historical or functional context comment on these? (@skinkie and others!).

Unsure at this point if these are false positives / issues with the review, or something that deserves actual changes possibly.

Potentially (???) missing xsd:key Replacements

* AlternativeName_UniqueBy_Id_Version_useForLanguage_ordered - Alternative names with language/order constraint

* AlternativeText_UniqueBy_Id_AttributeName_UseForLanguage_Version - Alternative text with 4-field uniqueness (`@id`, `@attributeName`, `@useForLanguage`, `@version`)

* Vehicle_UniqueRegistrationNumber - Vehicle registration number uniqueness constraint

* Call_UniqueBy_Id_Version_Order - Call element uniqueness with ordering

* DynamicDistanceMatrixElement_UniqueBy_Id_Version - Dynamic distance matrix element constraint

You are right @thbar whenever there is a unique, but no corresponding key, we need to keep the unique (unless there is a functional reason to drop it) .. so these unique need to be brought back (I only check a few from your list, but the principle is Ok)

[thbar]

Ping @TuThoThai @skinkie @ue71603 regarding the potentially missing constraints (#998 (review)): for each of them, do you see the same issue as me? Do you consider we need to add a xsd:key for those, business-wise?

(I will try to look a bit closer as time permits, but your input will be definitely worthy).

[TuThoThai]

As of 13 March 2026:

• roll back the deletion of unique constraints on AlternativeName, AlternativeText, Vehicle_UniqueRegistrationNumber, Call, DynamicDistanceMatrixElement
• assess if any other are missing

@ue71603, @thbar & @TuThoThai

[TuThoThai]

@skinkie, @thbar, @ue71603, I rolled-back some the deleted unique contraints when there was no matching key contraints in 2 commits:

• 83c522b is for NeTEx_publication.xsd
• 9225c05 is of NeTEx_publication_timetable.xsd

[thbar]

Heads-up @TuThoThai: I have identified (teaming up with 🤖 AI) a few cases that are not validated anymore hence regressions compared to master behaviour (I have isolated reproductions): TemplateVehicleJourney, GroupOfLinkSequences and SectionInSequence.

I will provide failing examples, so that we can use the build status here as a signal.

I am considering opening a sister-PR (either from v2.0 or from v2_remove_unique here) to add these "failing examples" + adapt CI tooling, WDYT?

[skinkie]

@thbar you mention that things start to fail. How can something fail if something is removed.

[thbar]

@thbar you mention that things start to fail. How can something fail if something is removed.

@skinkie we lack "failing examples" (things that are supposed to fail if we remove something essential, like a uniqueness constraint). I will present a PR that adds some checks that must fail for the PRs to pass, something that is not present in the repo at the moment if I read correctly.

[thbar]

(not to say that we necessarily need to integrate that into the CI all the time, it could be kept as separate reproductions, but if removal of 8k lines introduces regressions, we need to find ways to spot them reliably)

[thbar]

(will provide failing examples later)