Required IdType fixes #471

skinkie · 2023-07-26T17:56:44Z

This pull request tries to address the missing required "id" attributes. This is selected by:

GeneralFrameMembers (they must have id, no question)
Keyrefs that are already modelled in the NeTEx_publication file

I may have added too many, which I certainly will review. For the following objects there are IdTypes defined, but there is no individual id attribute modelled, this should still be done.

CustomerService
Entrance
FareContractEntry_
GeneralFrameMember
OtherOrganisation
PassengerCarryingRequirementsView
PassingTimeView
Point
ServiceAccessRight_
SignEquipment
TravelSpecification_
TypeOfEntity
VehicleMeetingPlace_
Zone

PassingTimeView and PassengerCarryingRequirementsView are likely a bug in the schema that introduces them in the GeneralFrame. For PassingTimeView a DataManagedObjectView is first introduced, and never used after. For PassengerCarryingRequirementsView in my guess invalidly a DataManagedObject is used (see: #474)

skinkie · 2023-07-26T18:36:18Z

Failing examples must be fixed. Already checked with the cardinality in the documentation.

something went massively wrong...

This reverts commit f7997ad.

This reverts commit 2b466ef.

This reverts commit 20e6fd6.

ue71603 · 2023-07-28T10:46:58Z

xsd/netex_part_1/part1_ifopt/netex_ifopt_site_version.xsd

-			<xsd:documentation>A physical entrance or exit to/from a SITE. May be a door, barrier, gate or other recognizable point of access.</xsd:documentation>
+			<xsd:documentation>A physical entrance or exit to/from a SITE. Maybe a door, barrier, gate or other recognizable point of access.</xsd:documentation>
 		</xsd:annotation>
+		<!-- TODO: Matthias


Adding all this stuff is no good idea. It is already there in Entrance before. That is why the ambiguity occurs.
An id is also there:

Is the problem that it is not required?

What we try to achieve here is that the attribute id gets overridden later with a specific ObjectIdType for that specific element. Theoretically we could add a regular expression then that would guard that the object is named like "codespace:ScheduledStopPoint:something". Not my intention now, but building the relationship between Ref and Id is.

…TEx-CEN/NeTEx into fix_attribute_id_use_required

skinkie · 2023-07-28T10:59:42Z

xsd/netex_part_1/part1_ifopt/netex_ifopt_site_version.xsd

 		</xsd:complexContent>
 	</xsd:complexType>
-	<xsd:element name="VehicleEntrance" abstract="true" substitutionGroup="Entrance">
+	<xsd:element name="VehicleEntrance" abstract="true" substitutionGroup="SiteComponent">


This kills the method resolution order (MRO) of the schema. Hence VehicleEntrance will be at the same level as Entrance, while what we want is having the inheritance.

I think we have a problem already, because Entrance comes from SITE and VehicleEntrance probably should not be a SITE. Or do I read this wrong?

It also might be one of the cases where we need an Entrance_ . Because having to restrictions in a row is not allowed in the inheritance. Should I try to model an Entrance_? According to one of the examples?

Or we should do the inheritance through the VersionStructure elements. I think that only in the "leaves" the id stuff can be done once.

I think this is a case where Entrance_ would make sense. In this situation I also want to figure out why (or not) Entrance_ may (or may not) be abstract.

skinkie · 2023-08-03T11:05:40Z

xsd/NX.xsd

 							<xsd:complexType>
 								<xsd:sequence>
-									<xsd:element ref="Point" maxOccurs="unbounded"/>
+									<xsd:element ref="Point_" maxOccurs="unbounded"/>


Are you sure about these changes? It feels like you are referencing to 'abstract' datatypes / 'containers'.

I am an engineer (not true): It works... And it seems to me that they did it that way on other xxx_ elements. What it does it references the "concrete" element that is used in the substitutionGroup. Otherwise it wouldn't work. But to be sure we would need a comment from Nick or Christophe.

@nick-knowles @Aurige

This is a bit different from the topic of the PR ;-) but technically should be Ok: I think that this is replacing a ref to anything inheriting from Point to anything being of in the Point_ substitution group. I didn't check the possible semantic impact (yet).

Aurige · 2023-09-06T17:40:06Z

I'm not sure that we can be so systematic ! A commented in other PR, I agree that any standalone object that can be referenced should be enforced to have an Id, but when it's an object that is embedded in the XML hierarchy and that will never be referenced, this constraint does not really makes sense (also it is harmless ... except that it brakes existing data).
For example, take the very first example you had to update : the <LimitingRuleInContext> is embedded, and giving it an Id is a constraint that is useless.
I will add this as a discussion point fir next meeting.

skinkie · 2024-08-06T13:05:43Z

@ue71603 in essence this is the problem with order in skinkie/reference#65 so if we on one hand have defined it as key element and thus compound key, and in the XML Schema it is optional. That is never going to work.

ue71603 · 2024-08-06T13:22:03Z

In my view objects have id. One does not know if it will be referenced. They also may not be generated at the same time in the same process.

TuThoThai · 2025-09-23T15:44:17Z

~~Group agreement:~~
~~- Ok for the fixes~~
~~- Can be merged after the examples are fixed by @skinkie~~

TuThoThai · 2025-10-08T12:23:46Z

Edit as of 10 Oct. 2025

From plenary meeting (23 Sept. 2025):

Group agrees that id should always exist from v2.0 onwards.
But cannot be targeted to master
And has too many mixed commits
Check consistency with constraints in netex_publication to avoid duplication of constraints

Actions:

moved to milestone v2.1
split the PR into several pieces

skinkie · 2025-10-08T13:42:49Z

@TuThoThai
I disagree with moving this to 2.1. This was agreed as late work for 2.0.

TuThoThai · 2025-10-08T14:59:23Z

@skinkie, noted on your disagreement (disappointment).
We had to mitigate between realistic time we had to solve the conflicts, double check on possible constraints duplicates in NeTEx publication, and pressing requests to have a XSD ready for the CEN vote.

I suggest:

we focus on the release of v2. 0
we leave it targeting master for bug fixes of the future v2. 0
if needed, we could move it to a "no milestone" and prioritise it for bug fixes

Would it be an acceptable route for you?

TuThoThai · 2025-10-09T13:06:46Z

Release meeting as of 9 Oct 2025:

Agreement to move it to v2.0 release
@skinkie to rework it based on PR First referencing class constraints #962
@Aurige, @thbar and @TuThoThai to review
Then, merge

Deadline: 14 Oct 2025

Aurige · 2025-10-10T09:25:14Z

To complement yesterday's discussion, I wanted to be back on the fact that most IDs are already mandatory due to the constraints. For example, on ScehduleStopPoint we have (this is not uniqueness, that's a mandatory key)

		<xsd:key name="ScheduledStopPoint_AnyVersionedKey">
			<xsd:selector xpath=".//netex:ScheduledStopPoint | .//netex:FareScheduledStopPoint"/>
			<xsd:field xpath="@id"/>
			<xsd:field xpath="@version"/>
		</xsd:key>

Therefore if you try to write

				<ScheduledStopPoint>
					<Name>Poste, St Jean</Name>
					<Location>
						<Longitude>-0.2071397147</Longitude>
						<Latitude>51.4217482061</Latitude>
					</Location>
					<VehicleModes>bus</VehicleModes>
				</ScheduledStopPoint>

You will get an error ... this on in XMLSpy

so the use="required" added on IDs, is really doubling this constraint, furthermore is is not comprehensive since it it is not including the version part of the constraint. So why not just adding the possibly missing constraints ?

In any case, this PR does not harm and I won't be against it, but I'm still not sure that it is the best way to go.

skinkie · 2025-10-10T09:39:54Z

Code generators (Java, Python, etc.) won't know anything about xsd:keys. They only consider the attribute.
The identity key contraints fall apart if attributes are missing. So if field @id or @Version is missing: it won't even report an error.

trurlurl · 2025-10-10T13:54:39Z

xsd/netex_framework/netex_genericFramework/netex_accessibility/netex_acsb_accessibility.xsd

 						</xsd:sequence>
 					</xsd:sequence>
-					<xsd:attribute name="id" type="LimitationIdType"/>
+					<xsd:attribute name="id" type="LimitationIdType" use="optional"/>


This is one of very few cases of optional uses. I guess this is as intended and it just is not clear to me why.

TuThoThai · 2025-11-19T14:20:11Z

Unless mistaken, this one can be closed as it was addressed by the combo of #970 and #972

Could you confirm the status, @skinkie?

skinkie · 2025-11-19T14:23:29Z

@TuThoThai I guess no champagne on Friday?

More required IdType fixes

4ec8571

skinkie added the enhancement non semantic enhacement: technical enhancement, etc. label Jul 26, 2023

skinkie requested review from Aurige, nick-knowles, trurlurl and ue71603 July 26, 2023 17:56

skinkie self-assigned this Jul 26, 2023

skinkie added 3 commits July 26, 2023 19:57

Typo

cd4a6f3

Remove required ids from DerivedViews

b034777

VehicleJourneyRunTime has a cardinality of 0:1

6a8e19b

skinkie and others added 13 commits July 27, 2023 12:09

Introducing new restrictions, and TODO's

4cf88c0

Better, but still failing

8066af4

More improvements, including required order properties

d6e3660

test for change of one of the TODO

20e6fd6

something went massively wrong...

Update netex_ifopt_site_version.xsd

2b466ef

Update netex_ifopt_site_version.xsd

f7997ad

Revert "Update netex_ifopt_site_version.xsd"

2301590

This reverts commit f7997ad.

Revert "Update netex_ifopt_site_version.xsd"

68338ca

This reverts commit 2b466ef.

Revert "test for change of one of the TODO"

a72adc6

This reverts commit 20e6fd6.

Fix id on InterchangeRuleTiming on VDV452 example.

4fe6625

Update FlexibleServiceProperties in NOPTIS example.

8abed5f

Fix DestinationDisplayVariant example

7db58d3

Introduce VehicleTypeZoneRestriction id and version attributes

9b167f1

ue71603 reviewed Jul 28, 2023

View reviewed changes

ue71603 added 2 commits July 28, 2023 12:57

Entrance, VehicleEntrance change

bb90df4

Merge branch 'fix_attribute_id_use_required' of https://github.com/Ne…

b0cfdbd

…TEx-CEN/NeTEx into fix_attribute_id_use_required

skinkie commented Jul 28, 2023

View reviewed changes

ue71603 and others added 2 commits July 28, 2023 15:28

adding Entrance_

198c470

Fix TopographicProjection required id and version

0097ce5

Lint and update documentation tables

a84cde5

skinkie commented Aug 3, 2023

View reviewed changes

skinkie mentioned this pull request Oct 3, 2023

PassengerCapacity@id #515

Closed

Aurige mentioned this pull request Oct 17, 2023

Conflicting example for Version elements #208

Closed

ue71603 added the group_decision_needed label Nov 21, 2023

ue71603 added this to the netex_1.2 milestone Dec 1, 2023

ue71603 added late_work and removed group_decision_needed labels Dec 14, 2023

ue71603 modified the milestones: netex_1.2, netex_2.0 May 1, 2024

skinkie mentioned this pull request Jan 29, 2025

Embedding allows to add non-interesting classes in the embedding table skinkie/reference#234

Closed

TuThoThai modified the milestones: netex_2.0, netex_2.1 Oct 8, 2025

TuThoThai modified the milestones: netex_2.1, netex_2.0 Oct 9, 2025

This was referenced Oct 9, 2025

Milestone v2.0 -- Release ongoing #963

Open

First referencing class constraints #962

Merged

trurlurl reviewed Oct 10, 2025

View reviewed changes

Required IdType fixes #471

Are you sure you want to change the base?

Required IdType fixes #471

Uh oh!

Conversation

skinkie commented Jul 26, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

skinkie commented Jul 26, 2023

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!

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!

Aurige commented Sep 6, 2023

Uh oh!

skinkie commented Aug 6, 2024

Uh oh!

ue71603 commented Aug 6, 2024

Uh oh!

TuThoThai commented Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TuThoThai commented Oct 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

skinkie commented Oct 8, 2025

Uh oh!

TuThoThai commented Oct 8, 2025

Uh oh!

TuThoThai commented Oct 9, 2025

Uh oh!

Aurige commented Oct 10, 2025

Uh oh!

skinkie commented Oct 10, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TuThoThai commented Nov 19, 2025

Uh oh!

skinkie commented Nov 19, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

skinkie commented Jul 26, 2023 •

edited

Loading

TuThoThai commented Sep 23, 2025 •

edited

Loading

TuThoThai commented Oct 8, 2025 •

edited

Loading