ET and stop-level cancellations - expected behavior

[JSH]

All,

First off, my apologies, I am sitll in the process of reading
documentation regarding SIRI (specifically prCEN/TS 00278181 parts 1,
2, & 3)

I am working with ET (SIRI 1.0) and found that the implementation by
our vendor presented some surprises.

My sample size is still small but so far only 1 out of 5 curtailments
has caused any sort of result within ET. The one successful
curtailment affected a trip 90 minutes into the future; all the calls
within the pattern were marked as cancellations.

1 - when a dispatch measure that resulted in service curtailment was
enacted, we usually did not see any indication in ET that stops would
no longer be serviced. . We are assuming this is a bug and will be
working with the vendor.

2 - when the successful curtailment was enacted, it took 15 minutes
for ET to reflect the cancellations. Again, we will be bringing this
up with the vendor and I need to do a documentation search to
determine if this delay should be expected.

3 - (and this is the real issue that I am puzzling over) when the
successful curtailment was undone (i.e. it was returned to service),
ET remained silent. I would have expected that ET would have presented
a complete pattern with all of the calls restored.

After a a quick scan of the SIRI documentation, I feel confident that
I should expect to see cancellations as a result of service
curtailments. What I am not confident about is the assumption that
when service that has been cancelled and that cancellation is then
reversed, should there not be ET messaging indicating that the calls
(or the journey, for that matter) is no longer cancelled, presumably
by the absence of the cancellation element?

Can anyone comment on this last point?

Thanks,
Jason

[Jay]

I agree there isn't much details in SIRI specifications but it is purely between the consumer and publisher to agree how they want to deal with the situations which are not specifically mentioned in the specification like your case below. 

What we are doing is, when service is marked as cancelled, we are setting "cancelled" flag as' true' and removing EstimatedTime elements but as soon as cancellation is reverse, we would start including the predictions (Estimated times) for that stop which is the indication that cancellation is now rolled back. 

Hope that answers your query.

Thanks,

JS