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: 158
Registered: March 2016
Senior 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: 87
Registered: March 2016
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: 439
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: 87
Registered: March 2016
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: 68
Registered: March 2008
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 – Common Schema Coordinator
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 messageGo to next message
Dominik Looser is currently offline  Dominik Looser
Messages: 18
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

Re: [railML3] missing @ruleCode? [message #2911 is a reply to message #2407] Sat, 19 February 2022 23:48 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 439
Registered: January 2016
Senior Member
Dear railML community,

in order to close this issue with upcoming railML 3.2, I want to ask you:
Which of the three options raised by Dominik do you prefer?

Dominik Looser wrote on Wed, 25 March 2020 11:01
Dear all,
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
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 #2967 is a reply to message #2911] Fri, 18 March 2022 12:46 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 158
Registered: March 2016
Senior Member
Dear railML community,

Jernbanedirektoratet recommends the use of <typeDesignator> for the described UC.
The reason being that an attribute @ruleCode is obvious not powerful enough to describe both the register and the entry in a unique manner without merging the two values. The use of <designator> would water out the principle that <designator> is used to designate individual items. Thus, the use of <typeDesignator> would be best suited to univocally define the type of item. (here signal or board) We also thought about adding attributes like an enumeration list @kind or a boolean attribute @isType in <designator>, but concluded that this might also muddle <designator> breaking the principle we stated earlier.
Re: [railML3] missing @ruleCode? [message #2968 is a reply to message #2967] Fri, 18 March 2022 13:26 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 439
Registered: January 2016
Senior Member
Dear Torben,

thank you for your feedback. I adapted the Git issue #443 [1] accordingly.
Just one last question: we will implement the <typeDesignator> for all functional infrastructure elements. Or would you like to limit it to some functional infrastructure elements only (which ones?)?

[1] https://development.railml.org/railml/version3/-/issues/443

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 #2969 is a reply to message #2968] Fri, 18 March 2022 14:07 Go to previous message
Torben Brand is currently offline  Torben Brand
Messages: 158
Registered: March 2016
Senior Member
Yes, we at Jernbanedirektoratet agree that it makes sense to implement <typeDesignator> for all functional infrastructure elements and let the user decide where it would be relevant to use them.
Previous Topic: [railML3] Loading gauge profile
Next Topic: [railML3] Identifiers in Infrastructure
Goto Forum:
  


Current Time: Mon Jun 17 03:29:53 CEST 2024