Adding DeadRun flag to SIRI for ET and VM

[TuThoThai]

Context

Since we have the possibility to have dead runs in NeTEx, it would be interesting to be able to follow them in SIRI-VM (mostly) and in SIRI-ET. It would allow to address these use cases:

• Have an explicit mention of a dead run that can be used for passenger information, especially when unplanned
• Support fleet monitoring regardless of the ServiceJourney type (accepting passengers or not).

Changes made in this PR

• In the XSD, more precisely in siri_journey.xsd in the JourneyInfoGroup, addition of an optional boolean named DeadRun7 with the default value being false`
• One example of a payload in SIRI-ET that includes a dead run
• One example of a payload in SIRI-VM that includes a dead run

[haeckerbaer]

approved but maybe check the sentence "so it is clear that only there is no expectation of an associated service to it" again.

[TuThoThai]

@haeckerbaer, thanks for pointing the unclear documentation. I have fixed it for your review!

[Ulf9]

1. I think there is a problem having a default value in relation to backward compatibility. Currently the element does not exist and that means it is undefined. It is not limited to be only a ServiceJourney, it could be a DeadRun as well.

So if this new element is to be added there should not be any deafult-value. Instead if used it must be explicit if the value is false or true.

2. Maybe it should instead by named differently with an enumeration DEAD_RUN, SERVICE_JOURNEY

[TuThoThai]

As per the SIRI plenary meeting of 29 September 2026, the PR is approved with the following changes:

• change the boolean name to IsDeadRun
• remove the default value to the boolean
• edit the examples consequently
• in the ET example, add Calls for the dead run

Changes have just been committed, so the PR is ready for your review @albanpeignier, @Aurige, @haeckerbaer, @skinkie, @thbar, @Ulf9

[TuThoThai]

1. I think there is a problem having a default value in relation to backward compatibility. Currently the element does not exist and that means it is undefined. It is not limited to be only a ServiceJourney, it could be a DeadRun as well.

So if this new element is to be added there should not be any deafult-value. Instead if used it must be explicit if the value is false or true.

2. Maybe it should instead by named differently with an enumeration DEAD_RUN, SERVICE_JOURNEY

Investigation was done for the the use of an enumeration coming from NeTEx. Making this element an enumeration would have forced to have the values for different types of Dead Run but also Service Alteration.
As of NeTEx v2.0, there is no more enumeration that would distinguish only Dead Run from other types of Service Journey