IL:keyLockInState

From railML 3 Wiki
Jump to navigation Jump to search

Introduction

Documentation

Syntax

Autoexport from the XML-Schema for element IL:keyLockInState of railML® version 3.3
    
Documentation reference to any key log and its state inside or outside the work zone required for use and/or protection
Subschema interlocking
Parents*

emergencyStopArea, localOperationArea, workZone

Children

designator (0..*), elementState (0..*), givenState (1..1)

Attributes:
  • protectingSide: indication whether the required state is for protection of the area from inside or outside (optional; xs:string)
Possible values:
  • inside: the protection of the related element is effective against railway traffic from the inside of an area
  • none: the related element gives no protection at all
  • outside: the protection of the related element is effective against railway traffic from the outside of an area,

  • id: the identifier of the object; this can be either of type xs:ID or UUID (obligatory; xs:ID); 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 IL:keyLockInState of railML® version 3.2
    
Documentation reference to any key log and its state inside or outside the work zone required for use and/or protection
Subschema interlocking
Parents*

localOperationArea, workZone

Children

designator (0..*), givenState (1..1)

Attributes:
  • protectingSide: indication whether the required state is for protection of the area from inside or outside (optional; xs:string)
Possible values:
  • inside: the protection of the related element is effective against railway traffic from the inside of an area
  • none: the related element gives no protection at all
  • outside: the protection of the related element is effective against railway traffic from the outside of an area,

  • 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 IL:keyLockInState of railML® version 3.1
    
Documentation reference to any key log and its state inside or outside the work zone required for use and/or protection
Subschema interlocking
Parents*

localOperationArea, workZone

Children

any (0..*), designator (0..1), givenState (1..1)

Attributes:
  • protectingSide: indication whether the required state is for protection of the area from inside or outside (optional; xs:string)
Possible values:
  • none
  • outside
  • inside,

  • 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 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.

The parents have been changed.

The children have been changed.

The attributes have been changed.

Semantics

Best Practice / Examples

Additional Information

Notes

Open Issues