Home » railML newsgroups » railML.infrastructure » [railML 2.5] state (Shall the state "unknown" be explicitly defined?)
[railML 2.5] state [message #2549] Fri, 09 October 2020 15:40 Go to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear all,

the element <state> is used in combination with several infrastructure elements in order to define these elements being in a certain state, e.g. "operational" or "disabled".

For defining an unknown state, we have two options:
* option 1: define a missing element <state> as being an unknown state
* option 2: add new explicit value "unknown" to the state enumeration

Which option do you prefer?

For more details, please check Trac ticket #421 [1]

Thank you very much and best regards
Christian

[1] https://trac.railml.org/ticket/421


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML 2.5] state [message #2551 is a reply to message #2549] Fri, 09 October 2020 15:58 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Hi Christian,

option 2, please.

Option 1 would mean that you change the default value (meaning) of <state>. So far, there was no "unknown" documented. So, we export infrastructure without <state> when we mean "operational" - we simply do not repeat the "operational" at all possible occurrences. Rather, we switch them off (with "disabled") in the (rare) case we haven an element which cannot be used. If you now define the default value as "unknown", all our existing railML files would immediately change their meaning from "operational" to "unknown".

I also want to remind here that "operational" or "unknown" cannot mean the actual state of the element; rather, they must be understood in the context of the certain railML file where they occur. Therefore, "operational" means: Used in the context in this railML file, or assumed to be operational here. No guarantee, no deduction allowed outside the railML file. It can be an element which is not even built jet, a proposed station for instance.

So to encode an element which is "unknown" is an even more rare and a bit strange case from our view. Of course all elements which are _not_ included in the railML file at all can be obviously unknown to the creator of that file.

With best regards,
Dirk.
Re: [railML 2.5] state [message #2715 is a reply to message #2551] Fri, 07 May 2021 11:22 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Dirk, dear all

thank you very much for your feedback. Proposed solution option 2 has been implemented in the upcoming railML 2.5 schema. For more information, please check the Trac ticket #421 [1].

[1] https://trac.railml.org/ticket/421

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML 2.5] state [message #2750 is a reply to message #2549] Fri, 04 June 2021 16:55 Go to previous messageGo to next message
Michael Gruschwitz is currently offline  Michael Gruschwitz
Messages: 11
Registered: May 2020
Junior Member
Dear all!

Am 09.10.2020 um 15:40 schrieb Christian Rahmig:
> the element <state> is used in combination with several
> infrastructure elements in order to define these elements
> being in a certain state, e.g. "operational" or "disabled".
>
> For defining an unknown state, we have two options:
> * option 1: define a missing element <state> as being an
> unknown state
> * option 2: add new explicit value "unknown" to the state
> enumeration
>
> Which option do you prefer?

We would prefer option 2 too.

Best regards,

--
Michael Gruschwitz
Bahnkonzept Dresden/Germany
Re: [railML 2.5] state [message #2753 is a reply to message #2750] Mon, 07 June 2021 17:14 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 66
Registered: March 2008
Member
Dear all,

My conclusion is that we need an explicit "unknown" value, but mostly to be able to override another value explicitly set higher in the hierarchy, e.g. an "operational" state on the whole infrastructure element. I do not agree with Dirk that option 1 changes the default value, because there is no default value. Any information that is not present in a file is unknown, unless a default value has been specified. The recipient may of course make reasonable assumptions, and the reasonable assumption when given an infrastructure model without any explicit state is that it represents an operational infrastructure. This is however not a defined default value, it is just a reasonable interpretation of (gaps in) the data.

When a producing system sends an explicit "unknown" value, it means that the value is actually unknown to the producing system. If a property is missing, on the other hand, it may be known or unknown to the producing system. To a receiving system it does not make much difference, the data is unknown either way, and assumptions may have to be made. The only difference is that with an explicit "unknown", it knows that the value is also unknown to the producing system.

I fully agree with Dirk's reminder about context.

Best regards,
Thomas


Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML 2.5] state [message #2758 is a reply to message #2753] Fri, 11 June 2021 16:04 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Thomas,

thank you for reminding us about the context related interpretation of the <state>@status value stressed by Dirk. I added this point into the Trac ticket #421 [1] and it should be added on the wiki page of element IS:state. Any further comments are very much appreciated...

[1] https://trac.railml.org/ticket/421

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: [railML2] modeling of a car ramp
Next Topic: railML 2.3 infrastructure extension proposal operational properties of an OCP
Goto Forum:
  


Current Time: Thu Mar 28 19:39:24 CET 2024