and its Data Dictionary
Since the only source of the TSO message structure and its data dictionary was the two PDF files published as CEN Workshop Agreements [43,44], I did not have any choice but to extract the data by converting the files into Microsoft Word and Excel format respectively. The incomplete schema extracted from [43] was then saved as an XML Schema Definition (XSD) file, although I had manually corrected many errors made by the PDF converter. However, extracting the data tables from the data dictionary was even harder. Since it would not be possible to construct the full
Table 6.1: TSO Message Structure defines some of the Elements and Sub-Elements [43]
Element
Name Hierarchy Type Cardinality Definition Notes or Value Domain
ID TSO_2_0 EVENT string (maximum 40 characters) REQUIRED, 1
Describes the identifier of the event for the creator of the TSO
This identifier shall be unique inside the node.
NAME TSO_2_0 EVENT string (maximum 40 characters) OPTIONAL, 0 or 1
Provides a name for the event
It is the responsibility of the node to have unique event names. MAIN_EVE NT_ID TSO_2_0 EVENT string (maximum 40 characters) OPTIONAL, 0 or 1
Provides a link to the main event
In this case, the current event is a sub-event of this main event ETYPE TSO_2_0
EVENT
group OPTIONAL, 0 or 1
The type of the event, which is the collation of several facets CATEGORY TSO_2_0 EVENT ETYPE String (maximum 80 characters) REQUIRED, [1..n]
The description of the scenario which leads to the event
For values see the TSO Code Definition. The complete list of values is in the data dictionary. ACTOR TSO_2_0 EVENT ETYPE string (maximum 80 characters) REQUIRED, [1..n]
Describes the type of the endangered object(s).
For values see the TSO Code Definition. The complete list of values is in the data dictionary LOCTYPE TSO_2_0 EVENT ETYPE string (maximum 80 characters) REQUIRED, [1..n]
Describes the type of the location where the event is taking place.
For values see the TSO Code Definition. The complete list of values is in the data dictionary ENV TSO_2_0 EVENT ETYPE String (maximum 80 characters) OPTIONAL, [0..n]
Describes the general environment (or context) of the event
For values see the TSO Code Definition. The complete list of values is in the data dictionary SOURCE TSO_2_0 EVENT String (enumeration) OPTIONAL, 0 or 1
Describes the origin of the declaration of the event
Possible values are: COMFOR (computer forecast), HUMDED (human deduction), HUMOBS (human observation), SENSOR (sensor observation).
schema manually, I wrote an application software for this purpose. However, I had to store the extracted data into an SQL Server database to enable the application to do the work. Storing this data into SQL Server database was not a straight forward process. First, I converted the source file into Microsoft Excel format and saved each table into a separate worksheet. This was done because Microsoft Access (a lightweight relational database application) can import each Excel worksheet as a
Table 6.2: Codes defined in TSO Data Dictionary (a) [44]
/EVENT/ETYPE/CATEGORY
Higher levels
Code Definition Additional description
1 ASB Anti social
behaviour
Anti social behaviour
2
ASR Assistance or rescue for person/animals
Assistance or rescue for person/animals
3 EXP Explosion Explosion
4 FIR Fire Fire
5 FLD Flood Flood
6 GND Ground Event Ground Event
7 HLT Health Health
8 POL Pollution Pollution
9 PSW Public
safety/welfare
Public safety/welfare
10 TRP Transport Transport
11 /ASB ABV Abandoned vehicle Vehicle that has been left unattended
12
/ASR ATM Smoke/un- breathable atmosphere
Atmosphere that requires specialist breathing apparatus to sustain life
13 /ASR HGT Rescue from a height Emergency rescue from a height above the normal reach of standard rescue equipment 14 /ASR ICE Rescue Ice Rescue of casualty from, on or under ice
15 /ASR MAR Marooned Person/s in a position or situation where self rescue is impossible 16 /ASR SIL Rescue silos/sand Rescue operations within silos
17 /ASR TRP Trapped Situation whereby a casualty cannot self rescue 18 /ASR UDG Rescue underground Rescue operations below ground level 19 /ASR WAT Rescue Water Rescue operations from water 20
/EXP AER Aerosols A gaseous suspension of fine solid or liquid particles, packaged under pressure with a gaseous propellant for release as a spray of fine particles
21 /EXP AMM Ammunition Explosives used in weapons such as bullet, shells, etc.
database (Access) table and SQL Server can import data from Access. SQL server cannot import data directly form Excel. Once the data importation and correction is complete, my application which is, in fact, an XML parser and generator, started building the complete schema. The core technique of developing the schema is explained below.
Notice the underlined text “/EVENT/ETYPE/CATEGORY” which is written just above the Table 6.2. The underlined text above the table says that all the elements listed in the table are sub-elements of ‘CATEGORY’, which itself is a sub-element of EVENT and ETYPE. We have learnt earlier in this chapter that ‘EVENT’ is one of the top-level elements of TSO that comes only under the root
Table 6.3: Codes defined in TSO Data Dictionary (b) [44]
/EVENT/ETYPE/ACTOR
Higher levels
Code Definition Additional description
1 /PPL/CHD BAB Baby (under 12 months) Baby (under 12 months)
2 /PPL/CHD INF INFANT (between 1 and 3 years) Less than 3 years (reduced mobility and understanding)
3 /PPL/CHD CHILD Child: between 3 years and 10 years
A child is approximately between 3 and 10 years.
4 /PPL/GND FML Female Female person
5 /PPL/GND MAL Male Male person
Figure 6.3: Hierarchy of some of the TSO Elements
element.
The first ten codes listed in the second column (Code) of the table do not have a corresponding value in the first column (Higher levels). This indicates that these ten elements are the direct child elements of CATEGORY as shown in Figure 6.3. For example, the hierarchical position of ASB will be /EVENT/ ETYPE/CATEGORY/ASB.
second column. This means ABV is a direct child element of ASB. Therefore, the hierarchical position of ABV will be /EVENT/ETYPE/CATEGORY/ASB/
ABV. Likewise, the codes in the rows from 12 to 19 are the direct child elements of ASR. Notice that the codes defined in Table 6.3 have two codes in the ‘Higherlevels’ column instead of one. Therefore, the parent elements of the first three codes in Table 6.3 is /EVENT/ETYPE/ACTOR/PPL/CHD and of the last two codes is /EVENT/ETYPE/ACTOR/PPL/GND. Thus, it is possible to identify the relative position of a TSO code from the data dictionary.
Before I explain how new elements from the data dictionary are added to the ex- isting (incomplete) schema, it is important to know about different types of elements an XML file can have. An XML file can have two types of elements:
1. Complex Element: A complex element can have any number of child elements that can be both simple and complex.
2. Simple Element: A Simple element cannot have any child element but a value of a single data type e.g. string, integer, dateTime, etc. If a simple element accepts only a certain number of fixed values, then those values are specified as its ‘enumeration’ values.
6.3.1
Adding new Elements to the Existing Schema
Suppose, CATEGORY (/EVENT/ETYPE/CATEGORY) is defined in the initial schema as a simple-type element. However, Table 6.2 indicates that CATEGORY can have multiple sub-elements. Hence, we need to declare CATEGORY as a complex-type element before appending any child element to it. However, if an element that can have sub-elements was already defined as a complex element, then sub-elements can be appended without making any change to the element (parent to be).
What would happen if the element CATEGORY (parent to be) was defined as an ‘enumeration’ value of another simple element?
Since the application adds only one new element/code at a time, if CATEGORY was an ‘enumeration’ value of another simple element then following changes would have to be made:
2. Define CATEGORY as a simple element.
3. Add the new code from the data dictionary as an ‘enumeration’ value of CAT- EGORY instead of defining it as a child element.
This process continues to ensure each code listed in the data dictionary is added to the schema. However, any code that is already included in the schema is skipped to avoid duplication. The top level elements of the complete TSO schema are shown in Appendix D.