Update netex_typeOfValue_version.xsd

[ue71603]

XMLSpy always had a problem.
This would fix it. But did I do it right? and then I would need to apply it to master too.

[thbar]

I'm not well versed enough to understand if that's good or not (and time is limited before release).

I wonder if that's something that could be delayed to v2.0.1 ?

cc @TuThoThai your opinion on this too?

[ue71603]

We certainly can delay it. The new XMLSpy always complaints about the XSD with two warnings.

[thbar]

Thank you @ue71603 ; this will give us time for testing. We'll create a milestone and move it to there.

[Aurige]

Why do we have these constraints here ? Shouldn't they be in Publication as all the other ?
The only happens a few time
\netex_framework\netex_responsibility\netex_responsibility_version.xsd
(Ln 182, Char 4) <xsd:unique name="KeyValuePair">
(Ln 231, Char 4) <xsd:unique name="PrivateCodeType">

\netex_framework\netex_responsibility\netex_typeOfValue_version.xsd
(Ln 178, Char 4) <xsd:unique name="TypeOfValue_Unique">

\netex_part_2\part2_frames\netex_serviceFrame_version.xsd
(Ln 130, Char 4) <xsd:unique name="SfUniqueLineId">

\netex_part_2\part2_frames\netex_serviceFrame_version.xsd
(Ln 130, Char 4) <xsd:unique name="SfUniqueLineId">

This is not harming, but to be consistent and avoid any double in the future, it may be worth moving them all to NeTEx_Publication.xsd

[TuThoThai]

SfUniqueLineId

Commit 6778f14 addresses this comment

[Aurige]

unique and key on the same attribute is redundant (key is enough)

[TuThoThai]

After discussion with @thbar, moving this to v2.0.1 to give us time to examine @skinkie latest comment and ensuring the CI is not failing

[thbar]

@TuThoThai I think we have more work on this to do ; given the need to ship, are you ok to move this to v2.0.1? EDIT: crossed messages 😄

[ue71603]

This is not really a KeyValue standard thing, but only uniqueness within the Type.
I already agreed to do it in 2.0.1.
However, when this is not solved all new XMLspys will report a warning an every time open that file as well and be there. So, to work with it, it is annoying.

[ue71603]

We should not have added the other problems to this PR which was on typeOfValue.

However, we are here now, and I think we just have to remove this:

		<!-- =====KeyValuePair unique============================== -->
		<xsd:unique name="KeyValuePair">
			<xsd:annotation>
				<xsd:documentation>Every Key Value Pair must be unique.</xsd:documentation>
			</xsd:annotation>
			<xsd:selector xpath=".//netex:KeyValue"/>
			<xsd:field xpath="netex:Key"/>
			<xsd:field xpath="netex:Value"/>
		</xsd:unique>
		<!-- =====PrivateCodeType unique============================== -->
		<xsd:unique name="PrivateCodeType">
			<xsd:annotation>
				<xsd:documentation>Every PrivateCode type must be unique.</xsd:documentation>
			</xsd:annotation>
			<xsd:selector xpath=".//netex:PrivateCode"/>
			<xsd:field xpath="@type"/>
		</xsd:unique>

This is in my view semantically wrong for KeyValue which are not primary keys and also probably for PrivateCode.

[ue71603]

PrivateCode is even worse. Because most will not use type it will try to do this across the board. For the id-attribute at least the class is used as well.
so I definitely want those to constraints gone.

[TuThoThai]

As of 13 March 2026:

• roll back this PR to only address the error netex_typeOfValue_version.xsd
• start a new issue / pull request to address the need (or not) of a constraint on KeyValue & PrivateCodeType and tag it for v3.0

To be done by @ue71603