| [railML 2.5] state [message #2549] |
Fri, 09 October 2020 15:40  |
christian.rahmig
Messages: 458
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  |
Dirk Bräuer
Messages: 313
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 |
christian.rahmig
Messages: 458
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 #2753 is a reply to message #2750] |
Mon, 07 June 2021 17:14 |
Thomas Nygreen
Messages: 74
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 |
christian.rahmig
Messages: 458
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
|
|
|
|
Members
Search
Help
Login
Home
