| Re: [railML2] Re: Extensions to railML for passenger information at stations [message #2420 is a reply to message #2418] |
Tue, 14 April 2020 20:10   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Hi Milan,
I am not sure what you mean with "only potentially". In a deterministic system, there should always be a cause for each effect. It seems to me that the cause should only not be exchanged in your use-case, or the cause should not be standardised by railML. A kind of "trigger=other:...", but surely not "trigger=none".
However, it is not important whether I understand it or not. I only want to ask you, as you yourself already know, to reduce wild-grow in railML. So if possible, please try to describe the actual trigger/cause for the announcement as tellingly as possible.
> 1) change announcementRef so that it is possible to neither
> specify a trigger nor periodic playback
In general, an attribute which end with "...Ref" should always be restricted to values of id's defined in the same railML file. I my opinion, this is a basic "common" rule at least in railML 2.
> 2) add a new trigger "manual" which specifies that the
> refered to announcement is not to be played unless a user
> decides otherwise
Sounds better than option 1 for me. It would be the right one in case the driver/conductor/guard presses a kind of button to trigger the announcement. In other cases - not linked to staff/humans - please specify the trigger in a more technical resolvable way - I think.
Best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
