This requirement applies to information concepts and data concepts. However, the requirement treats them differently. This difference is visualised below. In effect, a data concept needs to have an associated data type (coloured below). SWIM-INFO-012 places additional requirements on the usage of data types. The method for establishing the semantic correspondence for the different concepts is also different (see SWIM-INFO-016 and SWIM-INFO-017).
The figure below is used to show how the different concepts would appear in UML. In this case, the example is taken from AIXM 5.1.1. The AirportHeliport feature is an information concept as it has a name and a definition. It contains attributes such as locationIndicatorICAO which are data concepts - they have names, definitions and data types (CodeICAOType).
The specification requires only a minimum amount of details for the concepts. This reflects the focus on semantic interoperability. However, more details such as multiplicity and data value ranges can be added to the information definition. Indeed, the Specification for Service Descriptions, SWIM-SERV-022 requires more.
The note to the requirement in the Specification mentions that is possible to include "more details such as the relationships between concepts". This is often done by adding associations in UML models, or by using attributes to link different concepts. The Specification does not recommend one technique over the other. Indeed, the Specification does not mention techniques at all as the manner of adding relationships differs depending on the format used for the information definition.
[ ] The information definition contains a name for each of its information concepts and data concepts.
[ ] The information definition contains a definition for each of its information concepts and data concepts.
[ ] The information definition contains a data type for each of its data concepts.
[ ] There are no duplicated concepts in the same namespace within the information definition.
[ ] The concepts within the information definition are consistent with each other i.e. that concepts do not contradict each other.
[ ] The concepts within the information definition are consistent with their reference material.
[ ] Each concept's name, definition and data type are correct i.e. that they actually represent what they should.
The example below shows how a concept name could appear in an XML schema. It simply uses the name attribute of an element.
<xs:element name="tobt"> ... </xs:element>
The example below also shows how a concept's definition appears in an XML schema. It makes use the annotation element within the XML schema definition language.
<xs:element name="tobt"> <xs:annotation> <xs:documentation> <definition>The Target Off-Block Time value to be set. TOBT is the time that an operator / handling agent estimates that an aircraft will be ready, all doors closed, boarding bridge removed, push back vehicle present, ready to start up / push back immediately upon reception of clearance from the TWR.</definition> </xs:documentation> </xs:annotation> </xs:element>
The example below shows two ways to capture the data type information in an XML schema. The first states that the "ICAOAerodromeLocationIndicator" element is of type "xs:string". The second shows how an XML simpleType (using the same example) can be restricted to be a "xs:string". These example show different techniques for creating schemas but is not concerned with which is the better technique.
<xs:element name="ICAOAerodromeLocationIndicator" type="xs:string"> ... </xs:element> <xs:simpleType name="ICAOAerodromeLocationIndicator"> ... <xs:restriction base="xs:string"> ... </xs:restriction> ... </xs:simpleType>