XML Schema for CargoIMP

Introduction

The schema below are a set of XML message definitions for use by forwarders, carriers, ground-handlers and end-users.

They have been developed as working prototypes for use in applications that wish to send or receive cargo information, but prefer to use XML rather than Cargo-IMP directly. It is intended that they could form the basis of the future IATA message schema set.

Schema

The following are available for review/comment.

Message type	Schema version	Location	Example
Base types	1.1	ci_types.xsd	-
FSR	1.1	ci_fsr.xsd	fsr.xml
FSA(U)	1.1	ci_fsa.xsd	fsa.xml
FWB	1.1	ci_fwb.xsd	fwb.xml
FMA	1.1	ci_fma.xsd	fma.xml
FNA	1.1	ci_fna.xsd	fna.xml

Design guidelines

As we have developed these schema, we have used a set of ground-rules:

• We decided to stick as closely as possible to the current Cargo-IMP message definitions, rather than redesign the whole message set. This should make transition from Cargo-IMP to XML as straightforward as possible, from the point of view of the user, as the business content of the messages stay the same. It also minimises problems integrating with existing systems that may arise from datatypes having different names, formats, numbers of occurrence etc.
• Names of data elements have been taken from the Cargo-IMP definitions, with the spaces between words removed, and each word beginning with a capital letter (e.g. 'Number of Pieces' becomes NumberOfPieces).
• In designing schema there is always an issue over what should be elements and what attributes of elements. We have taken the approach that everything is an element, except for message version. This makes schema construction and message processing more straightforward.
• As there are a set of common lower level data elements, we have put these into a shared schema file (ci_types.xsd). This file is accessed in the individual message schema through the 'include' schema key word. Each of these data elements has the schema 'id' attribute set to the IATA Data Element Number, prefixed with 'IATA' e.g.<.. name="AWBSerialNumber" id="IATA113>. Some groups of base level elements often occur as a group (e.g. Quantity Detail). These we have made into compound elements, and given them ids with the 'CIT' prefix. For the schema to work together they need to have a common name-space, and we have used one based on the CCX domain. This will become the IATA domain in due course.
• The Cargo-IMP data element have different types - alphabetic, numeric etc., but all are held in the message as a sequence of ASCII characters. In order to reproduce the lengths, types and layouts, we have predominantly used the XML 'string' datatype, rather than the more natural 'int', 'date', 'decimal' datatypes.
• Some "Conditional" constructions have been hard to model precisely in the schema, and where it has not been possible to reproduce the behaviour exactly, the data item has been made optional, and an 'annotation' element added. This is not a severe handicap as traditionally the application producing the messages, must manage all the logic. The value of being able to model accurately in the schema means that anyone can, not only code a complete message from the schema, but also syntactically check the message against the schema automatically using a Public Domain validating parser.

Issues

Message version maintenance

These schema are based on specific versions of messages. What is needed is a generalised method for relating different versions of a message. The XSL Transformations (XSLT) language provides a standardised way for transforming one XML document into another. Publicly available XSLT scripts could be used to translate between versions, and would form part of the delivery of a new message schema by IATA.

Message Transport

XML messages can be transferred between users by any number of means, but a new standard, ebXML, is being developed by UN/OASIS, which covers issues of transport using FTP, Email, HTTP and SOAP, and also the related issues of sending receipts, and providing message 'signing' and encryption. This may provide a useful architecture for future cargo messaging needs.

Feedback

Please send your comments to webmaster.