With this post, we continue with the example of a "distant light signal with switchable speed announcement".

Note that one of the purposes here is to use ONLY infrastructure schema.

• "distant" ‒ <isAnnouncementSignal>

• "with speed announcement" ‒ isSpeedSignal @type = announcement

(1) So how should be the switchable aspect of a speed represented in railML 3.2?

(2) Is there a need to add the @isSwitchable attribute for <isSpeedSignal> child element in railML 3.3 to represent its switchable aspect?

There is the second option here, namely the usage of the <belongsToParent> element. There is no need for an additional @isSwitchable attribute for <isSpeedSignal> as the @isSwitchable attribute is present in the child signal.

Here the problem is that the semantics of the @belongsToParent attribute is quite ambiguous. Currently, it is suggested that the @isSwitchable attribute of a child signal overwrites the @isSwitchable attribute of a parent, not adding any further info. This produces the following problem. In principle, it should be possible to mix any kind of signals with each other. In case the milepost has a switchable aspect of a speed (in the child element), this makes the milepost to be switchable. But milepost is meant to have zero value of @isSwitchable attribute.

(3) So should be the switchable aspect of a speed represented by a child signal? In case yes, this implies that the implicit semantics of @belongsToParent should be changed in railML 3.3.

(4) Is there any other way to represent a switchable aspect of a speed for a signal using only infrastructure elements of railML 3.2?

(5) As distant signal ONLY announces the aspect of a main or combined signal, but never commands stop to a train [2], should <isTrainMovementSignal> child element be used?

<signalIS id="sig01" isSwitchable="true"> <!-- because the light is SWITCHABLE -->
    <name .../>
    <spotLocation ...>
        ...
    </spotLocation>
    <isTrainMovementSignal/>
    <signalConstruction type="light"/> <!-- because sig01 is LIGHT signal -->
</signalIS>
<signalIS id="sig02" isSwitchable="true"> <!-- because sig01 has SWITCHABLE speed announcement -->
    <name .../>
    <isSpeedSignal type="announcement"/> <!-- because sig01 has speed ANNOUNCEMENT -->
    <belongsToParent="sig01"/> <!-- because sig01 and sig02 are physically connected -->
</signalIS>
<signalIL id="sigil01" function="distant"> <!-- because sig01 is a DISTANT signal -->
    <refersTo ref="sig01"/>
</signalIL>