|
This requirements sets out the minimum detail needed to describe each element of the information that is exchanged. For example, if the exchange involves information about "aerodromes" the "aerodrome" element type should be described. This means the element type should be given a name, a description, etc based on the bulleted list in the requirement. The result is called an information definition.
Most of the details required are self-explanatory. The semantic correspondence of the element type with the AIRM is established following the requirements found in the Guidance on semantic correspondence section of the SWIM Information Definition Handbook.
The information definition should be complete, covering all of the element types that are exchanged, including a definition of service operation parameters, attributes and data types. However, the information definition can be provided in several ways e.g.:
Regardless of the option chosen, SWIM-SERV-023 AIRM conformance requires that the service description contains a statement on its AIRM conformance. This requirement affects SWIM-SERV-022; the information definition shall follow the semantic correspondence requirements in the EUROCONTROL Specification for SWIM Information Definition in order to provide evidence of its AIRM conformance.
It is best practice to base the information definition on the requirements found in the EUROCONTROL Specification for SWIM Information Definition, ensuring that it also contains the extra details required by this requirement. |
The EUROCONTROL Specification for SWIM Information Definition requires less detail to be provided for each element type: SWIM-INFO-007 Information definition concepts requires only a name, definition and (if needed) a data type. However, the specification also goes beyond what is asked for by the EUROCONTROL Specification for SWIM Service Description. For example, it requires that each element type has a unique identifier (SWIM-INFO-008 Unique identifiers for concepts) and a dedicated namespace. |
See the Information Definition section within the Donlon TOBT Setting Service Description.
The guidance below includes guidance for requirement SWIM-SERV-023 AIRM conformance. |
The guidance concerns JSON Schema v0.0.3 (see Schema releases).
|
Rules expressed for the cases as defined in Registry URD.
|
Within field informationDefinition (itself within field serviceInformationDescription) list one or more occurrences of type InformationDefinition.
A formal representation of information concepts or data concepts.
Rational: Enables to understand the information provided by the service, with a specific focus to the semantics of the information
attribute name | description | type | guidance | rule | |
---|---|---|---|---|---|
name | The name of the Information Definition. | string | Provide a name that indicates which part of all the information exchanged by the service is going to be described. In the absence of multiple parts a generic name can be provides e.g. Information Definition | Mandatory | |
description | The description of the Information Definition. | string | Introduce this information definition.
Make sure to have one or several service documents with type INFORMATION_DEFINITION. See Guidance on serviceDocument. | Mandatory | |
airmConformant | An indication whether the information definition used by the service conforms to the ATM Information Reference Model. | boolean | Indicate whether the service payload has semantic correspondence with the AIRM.
| Mandatory | |
airmVersion | The applicable version of the ATM Information Reference Model. | string | Guidance: Version of the AIRM that was used to establish semantic correspondence. Rule: Mandatory when airmConformant is true. No use otherwise. Note: Whether stand-alone or integrated, make sure the semantic correspondence is made available in a service document (see below).
| Mandatory Conditional |
The JSON Schema does not include attributes to describe all elements exchanged. The full description of the information definition is provided as a service document.
Within "serviceDocument" field (itself within "serviceDescriptionReferences" field) create one or more instances of Document with type INFORMATION_DEFINITION.
See Guidance on serviceDocument on how to fill in documents.
When the semantic correspondence is made available as a separate document (id est not in the Information Definition), create an instance of Document with type AIRM_TRACE.. |
"serviceInformationDescription": { "informationDefinition": [ { "name": "Service Information Definition", "description": "The information definition is described in a separate document. This includes the semantic correspondence. See References.", "airmConformant": true, "airmVersion": "1.0.0" } ], } "serviceDocument": [ { "documentType": "INFORMATION_DEFINITION", "title": "TOBT Setting Information Definition", "version": "1.0", "description": "Information Definition for the DONLON TOBT Setting service. Includes Semantic correspondence with traces to the AIRM", "reference": "public:/2019-09/TraceToAIRM.txt" } ] } } } |
A complete JSON example is available in page JSON example - Donlon TOBT Setting service description.