Home » railML newsgroups » railml.infrastructure » [railML3] missing @ruleCode? (railML3, @ruleCode)
[railML3] missing @ruleCode? [message #2345] Tue, 25 February 2020 11:37 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 89
Registered: March 2016
Member
It seems that the very practical attribute @ruleCode (in railML2) describing the type of signal in a national specific unique way is missing in railML3?

The type can be defined in railML2 (by @type and @function) and in a more detailed way in railML3 (by the used sub elements) in a railML generic way. But the national specific way needs also to be modelled. Both from an asset perspective (a home signal looks different in Germany than in Norway) and in an interlocking perspective. As the rules for a home signal can be different.
Re: [railML3] missing @ruleCode? [message #2358 is a reply to message #2345] Fri, 28 February 2020 06:33 Go to previous messageGo to next message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 27
Registered: March 2016
Junior Member
Hi,

from the brief description in wiki I am not sure about the use of @ruleCode. As it seems to be more functional related I
would see it more in SignalIL than SignalIS. In railML2 the attribute is just a plain string. However, the question is,
whether each signal will have its individual code or there is a limited list for an IM to choose from?

Can you explain your using of the attribute a little bit more?

Regards,
Jörg von Lingen - Interlocking Coordinator
Torben Brand wrote on 25.02.2020 11:37:
> It seems that the very practical attribute @ruleCode (in
> railML2) describing the type of signal in a national
> specific unique way is missing in railML3?
>
> The type can be defined in railML2 (by @type and @function)
> and in a more detailed way in railML3 (by the used sub
> elements) in a railML generic way. But the national specific
> way needs also to be modelled. Both from an asset
> perspective (a home signal looks different in Germany than
> in Norway) and in an interlocking perspective. As the rules
> for a home signal can be different.
>
Re: [railML3] missing @ruleCode? [message #2361 is a reply to message #2358] Fri, 28 February 2020 16:12 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 260
Registered: January 2016
Senior Member
Dear Torben,

I agree with Jörg: the content of railML 2 attribute @ruleCode seems to be better located in the interlocking domain of the signal since it refers to aspects the signal can show.

From my understanding, the information should be splitted in two aspects: the name/reference of the rule book (e.g. "Ril301" for DB's "Signalbuch") and the rule code of the signal in the referenced rule book (e.g. "SH2"). So, the structure of this information is very similar to the <designator> element, with the difference that a rule book is being referenced instead of an register and the entry is named rule code.

Best regards
Christian


Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] missing @ruleCode? [message #2363 is a reply to message #2361] Sat, 29 February 2020 05:10 Go to previous messageGo to next message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 27
Registered: March 2016
Junior Member
Just a remark.
If you speaking about the "coded name" of a signal aspect, the it shall be placed in the definition of the <hasAspect>
for the <specificIM>.

Regards,
Jörg von Lingen - Interlocking Coordinator
Christian Rahmig wrote on 28.02.2020 16:12:
> I agree with Jörg: the content of railML 2 attribute
> @ruleCode seems to be better located in the interlocking
> domain of the signal since it refers to aspects the signal
> can show.
Re: [railML3] missing @ruleCode? [message #2369 is a reply to message #2363] Wed, 04 March 2020 19:35 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 22
Registered: March 2008
Junior Member
Hi,

@ruleCode originatedas a way to include the national code of a stop post (and then more generally any signal). The given examples seem to me to be more about identifying the exact type of signal (e.g. to be able to look up its physical appearance), rather than its aspects. For boards there is little difference, as they have only one aspect. To provide an example, there are multiple light signal types (in any country) capable of showing the aspects "closed", "proceed" and "limitedProceed". In railML3 we can separate between some of these using <signalConstruction>@type and <signalIL>@function, but there may still be more than one type matching the @type and @function. How do you specify which specific type of signal it is? Another example is boards, where IL does not provide much, but where signalbooks usually have specific codes for each kind of board.

Best regards,
Thomas


Thomas Nygreen - Coordinator Across Schemes
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] missing @ruleCode? [message #2407 is a reply to message #2345] Wed, 25 March 2020 11:01 Go to previous message
Dominik Looser is currently offline  Dominik Looser
Messages: 1
Registered: March 2020
Junior Member
Dear all,

As this is my first forum post, it seems to be common here to introduce myself first. I work for trafit solutions gmbh in Switzerland and together with Jernbanedirektoratet we are working on railOscope/NRV with a railML-interface.

I also propose to include the @rulecode attribute in railML3 as the information we store there in railML2.4 cannot be placed in any other attribute.
The rulecode does not refer to a particular aspect of a signal, but only implies which aspects that signal has. Therefore, putting the rulecode into the aspects would only make sense for boards, where each board can only show one aspect.

I could also imagine Christian's idea to work: using a "designator-like" format for the rulecode. Since rulecodes already have a format like "NOR:TJN:§9-28", this could easily be split into a "register"(or rulebook) and an "entry". Designators now are used to store unique object-specific identifiers, while for rulecodes we need something not unique.

I see three possibilities now:
- A new @rulecode attribute is introduced in a future railML3 version.
- A new "designator-like" element is introduced with attributes @rulebook and @entry. This could be called <typeDesignator>.
- We use the existing <designator> element for "type designators" as well. Using several designators is already supported.

Best regards,
Dominik

[Updated on: Wed, 25 March 2020 11:03]

Report message to a moderator

Previous Topic: Station borders
Goto Forum:
  


Current Time: Mon Mar 30 13:14:08 CEST 2020