3 December 2007
AERONAUTICAL COMMUNICATIONS PANEL (ACP)
WG I – Internet Protocol Suite – 4th MEETING
Montreal, Canada, 3-7December 2007
XML Discussion
Presented by the Greg Saccone
- Introduction
Previous papers presented to the ACP discussed advantages of using XML as a data representation language and as a basis of a larger move to replace legacy data types such as those carried by AFTN and ACARS. In fact, there are some services currently offered by SITA and ARINC that allow ground-ground messaging via XML definitions. Additionally, ICAO is currently investigating a “Flight Plan Object” type definition which is envisaged to be defined in XML.
The current air-ground and ground-ground applications’ data definition is done via ASN.1. There was a question as to whether XML may be used for the IPS version of the ATN SARPs. It was decided that a closer look at XML versus ASN.1 should be conducted. This paper takes a more in-depth look
- Discussion
Both ASN.1 and XML are easily machine-readable, and to some extent, their usages by applications are very similar. Both can use set/get methods for individual data types that are automatically generated by development tools, and both can perform type checking before sending and upon receiving data.
A further comparison of XML and ASN.1 is discussed below:
Pros for XML
-Industry standard for SOA-type services and data definitions, includes developer resources
-Easily human readable (useful for debugging/monitoring type activities)
-Open source tools are available to help facilitate working with and defining XML
-Extensible; data elements can be added without breaking backwards compatibility (to a certain extent)
-XML schemas can be automatically generated from ASN.1 with some ASN.1 compilers.
Cons for XML
-Extensive tagging can make it bandwidth inefficient
-Representation is generally text-only; binary representation is encoded
Pros for ASN.1
-Strongly typed definition language that explicitly states types, ranges
-Encodes to bandwidth-efficient sizes
-Used by existing applications; commonality of data
-Extensibility markers allow backwards compatibility (to a certain extent)
Cons for ASN.1
-Compilers are generally not open source, expensive
-Not as widely used, although some notable applications make use of it (e.g. SNMP)
-If extensibility is not carefully used, backwards compatibility for new additions can be cumbersome
-Encoded data is not generally human readable, which can complicate debugging
The major considerations for XML include bandwidth efficiency and impacts on legacy architectures. Another important fact to note is that an XML schema can be generated from ASN.1. An example is given in the attachment. This would mean that an ASN.1 definition can be relatively easily translated into XML.
Bandwidth usage is a major concern in the near to mid term. Depending on the message types, there can be a factor of 2 – 8 times message size difference between an ASN.1-encoded message and an XML message (assuming ASN.1 Packed Encoding Rules are used). This is rather large and could have a significant impact on air-ground links. Ground-ground links have more capability in general, and are better suited to handle increases in bandwidth usage.
The impacts on architectures and applications of a move to XML would be more difficult to assess, as they would require a case-by-case investigation. Conceptually, setting and getting the data types within a structure could be very similar in XML and ASN.1; both call encoding/decoding type functions. However, depending on system design this may be prohibitively expensive.
- Conclusion
XML is a viable data definition to use for future aeronautical applications, with a principle current disadvantage of bandwidth (versus ASN.1). Also, the current ATN application’s ASN.1 definitions can be translated to XML via automated tools. In addition, other industry groups are addressing the specific data requirements of future air-ground applications, so the data definitions are likely to change.
Therefore it is recommended that the ASN.1 be maintained for the first version of the ATN IPS SARPs. The group can further discuss and investigate whether a companion XML definition should be produced from the agreed-upon data definitions when mature in order to facilitate future migration.
It should also be noted that Boeing is currently planning to investigate data-type independent implementations in order to minimize the impact of future data communication architectures.
1
Attachment – Example XML Schema from Compiled ASN.1
<?xml version="1.0" encoding="utf-8" ?>
xsd:schema xmlns:asn1=" elementFormDefault="qualified" xmlns:xsd="
xsd:import schemaLocation="asn1.xsd" namespace="
xsd:annotation
xsd:documentation This document was generated by the Objective Systems ASN1C Compiler
( Version: 6.04, Date: 29-Nov-2007. </xsd:documentation
</xsd:annotation
xsd:element name="cMAircraftMessage" type="CMAircraftMessage">
xsd:annotation
xsd:documentation PDU definition </xsd:documentation
</xsd:annotation
</xsd:element
xsd:complexType name="CMAircraftMessage">
xsd:choice
xsd:element name="cmLogonRequest" type="CMLogonRequest"/>
xsd:element name="cmContactResponse" type="CMContactResponse"/>
xsd:element name="cmAbortReason" type="CMAbortReason"/>
xsd:element name="cmServerFacilityQueryRequest" type="CMServerFacilityQueryRequest"/>
xsd:any namespace="##other" processContents="lax"/>
</xsd:choice
</xsd:complexType
xsd:element name="cMGroundMessage" type="CMGroundMessage">
xsd:annotation
xsd:documentation PDU definition </xsd:documentation
</xsd:annotation
</xsd:element
xsd:complexType name="CMGroundMessage">
xsd:choice
xsd:element name="cmLogonResponse" type="CMLogonResponse"/>
xsd:element name="cmUpdate" type="CMUpdate"/>
xsd:element name="cmContactRequest" type="CMContactRequest"/>
xsd:element name="cmForwardRequest" type="CMForwardRequest"/>
xsd:element name="cmAbortReason" type="CMAbortReason"/>
xsd:element name="cmForwardResponse" type="CMForwardResponse"/>
xsd:element name="cmServerFacilityQueryResponse" type="CMServerFacilityQueryResponse"/>
xsd:element name="cmServerFacilityUpdate" type="CMServerFacilityUpdate"/>
xsd:element name="cmSecureLogonResponse" type="CMSecureLogonResponse"/>
xsd:element name="cmSecureUpdate" type="CMSecureUpdate"/>
xsd:element name="cmEnhancedForwardRequest" type="CMEnhancedForwardRequest"/>
xsd:any namespace="##other" processContents="lax"/>
</xsd:choice
</xsd:complexType
xsd:element name="aPAddress" type="APAddress">
xsd:annotation
xsd:documentation PDU definition </xsd:documentation
</xsd:annotation
</xsd:element
xsd:complexType name="APAddress">
xsd:choice
xsd:element name="longTsap" type="LongTsap"/>
xsd:element name="shortTsap" type="ShortTsap"/>
</xsd:choice
</xsd:complexType
xsd:simpleType name="AircraftFlightIdentification">
xsd:restriction base="xsd:string">
xsd:minLength value="2"/>
xsd:maxLength value="8"/>
</xsd:restriction
</xsd:simpleType
xsd:simpleType name="Airport">
xsd:restriction base="xsd:string">
xsd:length value="4"/>
</xsd:restriction
</xsd:simpleType
xsd:simpleType name="AEQualifier">
xsd:restriction base="xsd:unsignedByte"/>
</xsd:simpleType
xsd:simpleType name="CMAbortReason">
xsd:union memberTypes="xsd:token">
xsd:simpleType
xsd:restriction base="xsd:token">
xsd:enumeration value="timer-expired"/>
xsd:enumeration value="undefined-error"/>
xsd:enumeration value="invalid-PDU"/>
xsd:enumeration value="protocol-error"/>
xsd:enumeration value="dialogue-acceptance-not-permitted"/>
xsd:enumeration value="dialogue-end-not-accepted"/>
xsd:enumeration value="communication-service-error"/>
xsd:enumeration value="communication-service-failure"/>
xsd:enumeration value="invalid-QOS-parameter"/>
xsd:enumeration value="expected-PDU-missing"/>
</xsd:restriction
</xsd:simpleType
</xsd:union
</xsd:simpleType
1