Adding PublicationRef and ConsequenceCode by TuThoThai · Pull Request #209 · TransmodelEcosystem/SIRI

TuThoThai · 2026-04-21T21:02:08Z

Request primarily made by the French mirror group.

Context - Real-life example

What is happening in real life:

Situation S: Unattended luggage in a metro currently stopped at the station “Saint-Paul” on the line 1 going toward “Château de Vincennes”
Consequence C1: No service between Hôtel-de-Ville and Château de Vincennes
Message MB: Unattended luggage. No service between Saint-Paul and Château de Vincennes
Consequence C2: Slow service between La Défense and Hôtel-de-Ville
Message MA: Unattended luggage. Slow service between La Défense and Hôtel-de-Ville

As of today, on the data consumers' side:

No possibility to track which ParametrisedAction relates to which Consequence
Whenever the Consequence evolve, they have to reprocess the entire payload to publish the right information

Hence, the double need:

Possibility to track a ParametrisedAction via an unique identifier
Possibility to add a link between a ParametrisedAction and a Consequence of a situation

Change request

Adding PublicationRef to identify a ParametrisedAction for easier updates on data consumers side
Adding ConsequenceRef in ParametrisedAction to strenghten the link between the Consequence of a Situation and its publication
Adding ConsequenceCode in PtConsequence as a unique identifier of the Consequence that can be referrenced elsewhere
It would allow something like this:

This request for change was discussed on 7 Apil 2026 in the SIRI-SX task force with positive outcome.

Need: Data consumers want to track the ParametrisedAction of one or several Consequences Change: - Adding `PublicationRef` to identify a `ParametrisedAction` for easier updates on data consumers side - Adding `ConsequenceRef` in `ParametrisedAction` to strenghten the link between the Consequence of a Situation and its publication - Adding `ConsequenceCode` in `PtConsequence` as a unique identifier of the Consequence that can be referrenced elsewhere

skinkie · 2026-04-22T07:34:18Z

I don't understand the need. For now -1.

TuThoThai · 2026-04-22T07:49:25Z

I don't understand the need. For now -1.

We discussed it at the previous SIRI-SX task force meeting. Let me detail the context to better reflect what was presented. 😊

==> Change done at the beginning of the PR

TuThoThai · 2026-04-22T08:55:12Z

On 22 April, discussions

add more details on the PR description with actual messages
suggested changed PublicationRef to PublishedRef

haeckerbaer

Please add an example that details in what scenarios these new references can/should be used (as already discussed in the SX task force). Otherwise approved

TuThoThai · 2026-07-15T19:06:10Z

@haeckerbaer , after your review I edited:

the description of the PR at the top
added an example

removal of typo Co-authored-by: Stefan de Konink <stefan@konink.de>

Clarifying the section without service to distinguish better the 2 consequences

fix the Affects part in the Consequence with noService

TuThoThai · 2026-07-16T09:13:01Z

@haeckerbaer , @skinkie and @thbar , I fixed the example. Ready for your final review!

rbnxx · 2026-07-21T11:54:50Z

it looks good.

skinkie

I want this being discussed in the group.

skinkie · 2026-07-21T12:03:27Z

 							<xsd:documentation>Data associated with action.</xsd:documentation>
 						</xsd:annotation>
 					</xsd:element>
+					<xsd:element name="PublicationRef" type="xsd:NMTOKEN" minOccurs="0">


I don't see why this should be tracked with extra references.

skinkie · 2026-07-21T12:04:45Z

 			<xsd:documentation>Type for disruption.</xsd:documentation>
 		</xsd:annotation>
 		<xsd:sequence>
+			<xsd:element name="ConsequenceCode" type="xsd:NMTOKEN" minOccurs="0">


This linking causes overly complex parsing. Notice that the example has multiple ConsequenceRef's.

@skinkie, indeed the example has multiple ConsequenceRef as it exactly describes the context presented at the top of the PR. The idea is that some PublishingAction can refer to several consequences while other are dedicated to only one consequence of the same situation.

I think is the wrong solution for the problem. It creates relationships within the document not able to be checked or enforced.

The problem to solve here is the case of a SituationExchange that has several different consequences and several messages describing the situation.

In this case, for a single SituationExchange, there can be several complementary messages (PublishingAction):

PublishingActions with a text that describes only one of the consequences (one action for each consequence)

A PublishingAction with a text that describes several consequences (one action describing all the consequences)

Depending on the context, a system using the SituationExchange needs to be able to choose between the more specific version of the message for a specific consequence (for example, a display at a specific bus stop for a specific line) or the broader version of the message whose text describes all the consequences in a single optimized message (for example, a display in the hall of a bus station to optimize screen usage).

The question is more in the direction: is the document structure wrong for this. If it does not logically flow that PublishingActions are related to Consequences.

The document structure does not seem fundamentally wrong to me.
Adding this kind of relationship between Consequence and PublishingAction is, in my view, similar to the SituationRef found in the SMDelivery (IIRC). It would provide an attribute indicating that a publishing action (i.e., a message) is associated with one or more consequences.

TuThoThai requested review from Aurige, haeckerbaer, skinkie, thbar and ue71603 April 21, 2026 21:02

TuThoThai added SX For everything SIRI-SX Needs CEN documentation Update These require CEN documentation update to match XSD & examples labels Apr 21, 2026

TuThoThai added this to the v2.3 milestone Apr 21, 2026

TuThoThai mentioned this pull request Apr 21, 2026

SX Lien Consequence vs Publishing Action etalab/transport-profil-siri-fr#36

Open

skinkie reviewed Apr 22, 2026

View reviewed changes

Comment thread xsd/siri_model/siri_situationActions.xsd Outdated

Apply suggestion from @skinkie

7fc8699

TuThoThai requested a review from skinkie April 22, 2026 08:04

haeckerbaer requested changes May 13, 2026

View reviewed changes

haeckerbaer and others added 3 commits June 9, 2026 08:04

Merge branch 'v2.3-wip' into sx_cr_link_actions_consequences

d618f9c

adding example

f962d68

Merge branch 'v2.3-wip' into sx_cr_link_actions_consequences

ff48378

TuThoThai requested a review from haeckerbaer July 15, 2026 19:05

Merge branch 'v2.3-wip' into sx_cr_link_actions_consequences

e45f07a

haeckerbaer previously approved these changes Jul 16, 2026

View reviewed changes

Lint and update documentation tables

14d11e7

TuThoThai dismissed haeckerbaer’s stale review via 14d11e7 July 16, 2026 07:48

skinkie reviewed Jul 16, 2026

View reviewed changes

Comment thread xsd/siri_model/siri_reference.xsd Outdated

github-actions Bot and others added 3 commits July 16, 2026 07:48

Lint and update documentation tables

ba1e42f

Lint and update documentation tables

aab68bf

Update xsd/siri_model/siri_reference.xsd

b34c06b

removal of typo Co-authored-by: Stefan de Konink <stefan@konink.de>

github-actions Bot and others added 6 commits July 16, 2026 07:52

Lint and update documentation tables

2d1f90d

Lint and update documentation tables

0d37d19

Lint and update documentation tables

e082dae

Lint and update documentation tables

ab36c0e

Clarifying the Affects of Consequence C1

05f6ee0

Clarifying the section without service to distinguish better the 2 consequences

Merge branch 'v2.3-wip' into sx_cr_link_actions_consequences

f0f64a0

haeckerbaer previously approved these changes Jul 16, 2026

View reviewed changes

fix example

2791a92

fix the Affects part in the Consequence with noService

TuThoThai dismissed haeckerbaer’s stale review via 2791a92 July 16, 2026 09:05

Lint and update documentation tables

12a51e4

TuThoThai requested review from haeckerbaer and skinkie July 16, 2026 09:15

haeckerbaer approved these changes Jul 16, 2026

View reviewed changes

Comment thread examples/siri_exm_SX/exx_situationExchange_response_multipleconsequences.xml Outdated

Comment thread examples/siri_exm_SX/exx_situationExchange_response_multipleconsequences.xml Outdated

ue71603 approved these changes Jul 16, 2026

View reviewed changes

skinkie requested changes Jul 21, 2026

View reviewed changes

Uh oh!

Conversation

TuThoThai commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Context - Real-life example

Change request

Uh oh!

Uh oh!

skinkie commented Apr 22, 2026

Uh oh!

TuThoThai commented Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TuThoThai commented Apr 22, 2026

Uh oh!

haeckerbaer left a comment

Choose a reason for hiding this comment

Uh oh!

TuThoThai commented Jul 15, 2026

Uh oh!

Uh oh!

TuThoThai commented Jul 16, 2026

Uh oh!

Uh oh!

Uh oh!

rbnxx commented Jul 21, 2026

Uh oh!

skinkie left a comment

Choose a reason for hiding this comment

Uh oh!

skinkie Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

skinkie Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

TuThoThai Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

skinkie Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

rbnxx Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

skinkie Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

rbnxx Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

TuThoThai commented Apr 21, 2026 •

edited

Loading

TuThoThai commented Apr 22, 2026 •

edited

Loading