IL:keyLockInState:givenState

From railML 3 Wiki
Jump to navigation Jump to search

Introduction

Documentation

Syntax

Autoexport from the XML-Schema for element IL:keyLockInState:givenState of railML® version 3.3
    
Documentation the tuple of references to the key lock and its state plus the level of enforcement
Subschema interlocking
Parents*

keyLockInState

Children

relatedLockAndState (1..1)

Attributes:
  • isNegated: The exclusion of a particular state, i.e. everything else that this one. (optional; xs:boolean),

  • mustOrShould: level of enforcement (optional; xs:string)
Possible values:
  • must: flag, that the given state of an element is mandatory
  • none: flag, that the given state of an element is neither “must” nor “should”
  • should: flag, that the given state of an element is desired but not mandatory,

  • proving: The way the state is proven. (optional; xs:string)
Possible values:
  • continuously: the status/position of a related element is continuously checked
  • oneOff: the status/position of a related element is only checked at the beginning
  • staffAcknowledged: the status/position of a related element is only checked by staff without any technical support
*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:givenState of railML® version 3.2
    
Documentation the tuple of references to the key lock and its state plus the level of enforcement
Subschema interlocking
Parents*

keyLockInState

Children

relatedLockAndState (1..1)

Attributes:
  • isNegated: The exclusion of a particular state, i.e. everything else that this one. (optional; xs:boolean),

  • mustOrShould: level of enforcement (optional; xs:string)
Possible values:
  • must: flag, that the given state of an element is mandatory
  • none: flag, that the given state of an element is neither “must” nor “should”
  • should: flag, that the given state of an element is desired but not mandatory,

  • proving: The way the state is proven. (optional; xs:string)
Possible values:
  • continuously: the status/position of a related element is continuously checked
  • oneOff: the status/position of a related element is only checked at the beginning
  • staffAcknowledged: the status/position of a related element is only checked by staff without any technical support
*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:givenState of railML® version 3.1
    
Documentation the tuple of references to the key lock and its state plus the level of enforcement
Subschema interlocking
Parents*

keyLockInState

Children

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

Attributes:
  • mustOrShould: level of enforcement (optional; xs:string)
Possible values:
  • none
  • should
  • must,

  • proving: The way the state is proven. (optional; xs:string)
Possible values:
  • staffAcknowledged
  • continuously
  • oneOff,

  • isNegated: The exclusion of a particular state, i.e. everything else that this one. (optional; xs:boolean),

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


 

Semantics

Best Practice / Examples

Additional Information

Notes

Open Issues