Forum - RDF feed
https://www.railml.org/forum/index.php
[railML2] Enhancing the <lock> element
https://www.railml.org/forum/index.php?t=rview&goto=2589&th=778#msg_2589
after the very basic implementation of the signaling element <lock> in railML 2.4 (see [1]), it has been suggested to extend it with upcoming version railML 2.5.
In particular, three modifications are proposed in Trac ticket #428 [2]:
* new attribute @positionAtTrack to describe the location of the lock left or right of the track
* new attribute @controllerRef to link the lock with the controller from where it is controlled
* new attribute @keyStorageRef to link the lock with the OCP where the key is stored in case it is not inserted in the lock.
Further, the question about "types of locks" remains: until further generalization of lock types enabling the introduction of an enumeration attribute, it is suggested to use the free text attribute @description for it.
Are there any objections against that railML 2.5 proposal?
Best regards
Christian]]>christian.rahmig2020-11-16T13:32:40-00:00Re: [railML2] Enhancing the <lock> element
https://www.railml.org/forum/index.php?t=rview&goto=2671&th=778#msg_2671
We suggest the coordinators double check if the suggested attributes in the previous and in this posting are also contained in [railML3].
We would like to suggest further adding two important attributes of the lock: its type and a reference to what it locks.
For railML3 I leave it to the coordinators to describe the type with either: @ruleCode, @kind, @type, @system or <designator>.
Reference to what the lock actually locks can be done either from the lock or to the lock. In railML2.4nor extensions we have the attribute @lockRef on the element <switch>, <crossing> and the <derailer>. But you could also have a subelement <takesControlOf> with an @ref attribute like in railML3. What does the community prefer?
]]>Torben Brand2021-02-25T07:57:00-00:00Re: [railML2] Enhancing the <lock> element
https://www.railml.org/forum/index.php?t=rview&goto=2687&th=778#msg_2687
Am 25.02.2021 um 08:57 schrieb Torben Brand:
> Reference to what the lock actually locks can be done either
> from the lock or to the lock. In railML2.4nor extensions we
> have the attribute @lockRef on the element <switch>,
> <crossing> and the <derailer>. But you could also have a
> subelement <takesControlOf> with an @ref attribute like in
> railML3. What does the community prefer?
We prefer the solution to have the attribute @lockRef on the element
<switch>, <crossing> and the <derailer> as it is implemented in the same
manner on the <controllerRef>.
Best regards,
--
Michael Gruschwitz
Bahnkonzept Dresden/Germany]]>Michael Gruschwitz2021-03-25T12:52:32-00:00Re: [railML2] Enhancing the <lock> element
https://www.railml.org/forum/index.php?t=rview&goto=2700&th=778#msg_2700
Best regards,
Joerg v. Lingen - Interlocking Coordinator
Am 25.03.2021 um 13:52 schrieb Michael Gruschwitz:
> Dear all!
>
> Am 25.02.2021 um 08:57 schrieb Torben Brand:
>> Reference to what the lock actually locks can be done either
>> from the lock or to the lock. In railML2.4nor extensions we
>> have the attribute @lockRef on the element <switch>,
>> <crossing> and the <derailer>. But you could also have a
>> subelement <takesControlOf> with an @ref attribute like in
>> railML3. What does the community prefer?
>
> We prefer the solution to have the attribute @lockRef on the element <switch>,
> <crossing> and the <derailer> as it is implemented in the same manner on the
> <controllerRef>.
>
> Best regards,]]>Jörg von Lingen2021-04-11T04:08:35-00:00