IS:infrastructureState

From railML 3 Wiki
Revision as of 13:09, 19 February 2025 by RailML Orga Ontology (talk | contribs) (→‎Invalid code)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


Railway construction © CC-BY MJJR; Source


Introduction

Documentation

Syntax

This element does not appear in railML® 3.3 within the IS subschema. It is available only in railML® 3.1, 3.2. Do not hesitate to contact railML.org for further questions.

Autoexport from the XML-Schema for element IS:infrastructureState of railML® version 3.2
    
Documentation state of the functional infrastructure regarding its availability and usability
Subschema infrastructure
Parents*

infrastructureStates

Children

elementState (0..*), name (0..*), validityTime (0..*)

Attributes:
  • value: railway infrastructure functional state, e.g. "operational" (optional; xs:string; patterns: other:w{2,}; consider Dev:UsingAny too.)
Possible values:
  • closed: The element is no longer available, removed, dismantled, or no longer exists. Planning, construction or commissioning activities are absolutely necessary for recommissioning.
  • conceptual: The construction or commissioning of the element is planned for the medium or long term. However, there are still no concrete (planning) activities for the construction of the element beyond the preliminary planning and cost estimation.
  • disabled: The element is currently not usable, switched off or deactivated and therefore cannot be used regularly. However, it can be put back into operation at short notice without further construction, acceptance or approval activities.
  • operational: The element is operational and can be used regularly.
  • planned: The construction or commissioning of the element is planned concretely and at short notice or concrete planning activities for the construction take place, e.g. design, approval or implementation planning, cost calculation, award of contracts. It is not normally possible to use the element.,

  • id: unique identifier (obligatory; xs:string; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}); compare: Dev:Identities
*Notice:
Elements may have different parent elements. As a consequence they may be used in different contexts.
Please, consider this as well as a user of this wiki as when developing this documentation further.
Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.

 

Autoexport from the XML-Schema for element IS:infrastructureState of railML® version 3.1
    
Documentation state of (a part of) the functional infrastructure regarding its availability and usability
Subschema infrastructure
Parents*

infrastructureStates

Children

any (0..*), elementState (0..*), name (0..*), validityTime (0..*)

Attributes:
  • value: railway infrastructure functional state, e.g. "operational" (optional; xs:string; patterns: other:w{2,}; consider Dev:UsingAny too.)
Possible values:
  • disabled: The element is currently not usable, switched off or deactivated and therefore cannot be used regularly. However, it can be put back into operation at short notice without further construction, acceptance or approval activities.
  • closed: The element is no longer available, removed, dismantled, or no longer exists. Planning, construction or commissioning activities are absolutely necessary for recommissioning.
  • operational: The element is operational and can be used regularly.
  • conceptual: The construction or commissioning of the element is planned for the medium or long term. However, there are still no concrete (planning) activities for the construction of the element beyond the preliminary planning and cost estimation.
  • planned: The construction or commissioning of the element is planned concretely and at short notice or concrete planning activities for the construction take place, e.g. design, approval or implementation planning, cost calculation, award of contracts. It is not normally possible to use the element.,

  • id: unique identifier (optional; xs:ID; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}); compare: Dev:Identities
*Notice:
Elements may have different parent elements. As a consequence they may be used in different contexts.
Please, consider this as well as a user of this wiki as when developing this documentation further.
Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.

 


Changes 3.1→3.2

There exists an overview of all changes between railML® 3.1 and railML® 3.2 on page Dev:Changes/3.2.

The element documentation has been changed.

The parents have been changed.

The children have been changed.

The attributes have been changed.

Changes 3.2→3.3

There exists an overview of all changes between railML® 3.2 and railML® 3.3 on page Dev:Changes/3.3.

Removed with version 3.3.

Semantics

Private-cloud-icon.png Proposed Semantic Constraint "IS:019":
 
When calculating which <infrastructureState> of an <infrastructure> is valid on a particular time always a maximum of one active <infrastructureState> shall be the result. See examples below.
 
Proposed on September 3rd 2024
FIXME: add Link to discussion!
Please, recognize our guidelines on semantic constraints

Invalid code

Reader cannot identify what is the state of the <infrastructure> in the file: "operational" or "conceptual", because validityTime is not given therefore not restricted. Both "operational" and "conceptual" states apply to the whole infrastructure except elements "xxx" and "yyy". 

      <infrastructureState id="state1" value="operational">
        <elementState id="xxx" refersToElement="zzz" value="closed" />
      </infrastructureState>
      <infrastructureState id="state2" value="conceptual">
        <elementState id="yyy" refersToElement="jjj" value="disabled" />
      </infrastructureState>

Valid code

Case 1 and case 2 below both and example of unambiguous description if infrastrucrure.

Case 1

There is only one <infrastructureState> in the file therefore it does not intersect with any other infrastructureState. elementState/@value gives other state than infrastructureState/@value and overwrites it for element "xxx". 

      <infrastructureState id="state1" value="operational">
        <elementState id="xxx" refersToElement="zzz" value="closed" />
      </infrastructureState>
Case 2

Validities of "state1" and "state2" do not intersect therefore in reader can identify when each of them applies.

This example provides the following information:

  • the whole infrastructure except element "xxx" from "2002-09-24-06:00" to "2002-09-30-06:00" was is state "operational".
  • element "xxx" from "2002-09-24-06:00" to "2002-09-30-06:00" was is state "closed".
  • the whole infrastructure except element "xxx" from "2022-09-24-06:00" to "2022-09-30-06:00" was is state "conceptual".
  • element "xxx" from "2022-09-24-06:00" to "2022-09-30-06:00" was is state "disabled".
  • the state from "2002-09-30-06:00" to "2022-09-24-06:00" is undefined.
      <infrastructureState id="state1" value="operational">
        <validityTime>
          <period from="2002-09-24-06:00" to="2002-09-30-06:00" />
        </validityTime>
        <elementState id="xxx" refersToElement="zzz" value="closed" />
      </infrastructureState>
      <infrastructureState id="state2" value="conceptual">
        <validityTime>
          <period from="2022-09-24-06:00" to="2022-09-30-06:00" />
        </validityTime>
        <elementState id="yyy" refersToElement="jjj" value="disabled" />
      </infrastructureState>


Best Practice / Examples

<infrastructureState> "state1" refers to the whole infrastructure. Children <elementState> refer only to the elements with different state. 

      <infrastructureState id="state1" value="operational">
        <elementState id="yyy" refersToElement="aaa" value="closed" />
        <elementState id="zzz" refersToElement="bbb" value="closed" />
        <elementState id="jjj" refersToElement="ccc" value="closed" />
      </infrastructureState>

Bad Practice

This is a bad practice because elementState/@value="closed" gives redundant fact. It is already know from the parent that all the IS except listed in children with different state is "closed". 

      <infrastructureState id="xxx" value="closed">
        <elementState id="yyy" refersToElement="aaa" value="closed" />
        <elementState id="zzz" refersToElement="bbb" value="closed" />
        <elementState id="jjj" refersToElement="ccc" value="closed" />
      </infrastructureState>

Additional Information

Notes

Open Issues

Retrieved from "https://wiki3.railml.org/index.php?title=IS:infrastructureState&oldid=12110"