| Re: [railml3] Signal types and functions [message #2148 is a reply to message #2145] |
Mon, 18 February 2019 14:55  |
christian.rahmig
Messages: 436
Registered: January 2016
|
Senior Member |
|
|
Dear Thomas,
Am 12.02.2019 um 14:34 schrieb Thomas Nygreen:
> [...]
>
> christian.rahmig wrote on Mon, 11 February 2019 15:51
>> The idea was to provide the information on two levels:
>>
>> - high level (only one word): using attribute
>> <signalIS>@type
>> - detailed level: using child element
>> <signalIS><is*Signal>
>>
>> Depending on the requirements resulting from the use
>> case, the information about the signal shall be modelled either in
>> one way or the other.
>
> In my opinion the combined approach leaves the type
> attribute completely redundant. As posted above I suggest to
> remove it and only use the child elements. If more detailed
> information is not available, the element may be empty.
> Keeping both leaves two separate ways to model the same
> information, increasing the load on both reading and writing
> systems.
You are right. If we allow empty child elements, the attribute @type
won't be necessary. So, are there any other opinions from the community?
> [...]
>
> christian.rahmig wrote on Mon, 11 February 2019 15:51
>> "board" can be considered as a new value for
>> <signalIS><signalConstruction>@type. It will be defined
>> as a "non-switchable semaphore signal". The enumeration value
>> "semaphore" would be used for switchable semaphore signals. Are
>> there any examples for non-switchable virtual signals?
>
>
> I do not understand why you consider a board to be a
> semaphore signal. A semaphore, by definition, conveys its
> meaning using the positions of its arms. A board is a
> separate signal type. It has no arms and does not fit the
> definition of a semaphore. Is this a German generalisation?
> Also, Tobias shows an example of a non-switchable semaphore
> (which is not a board).
My proposal: extend <signalConstruction>@type with value "board".
Together with existing values "light", "semaphore" and "virtual" we
should have a complete picture, haven't we?
Best regards
Christian
--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
