
Standardized Approach for Exchanging Supplementary Aeronautical Data
Explore the standardized approach for exchanging supplementary aeronautical data, including insights on ARINC data, runway surface types, and XML schema mechanisms. Discover the importance of extension points and the implications of handling supplementary data securely within the aeronautical information domain.
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
A Standardized Approach for Exchanging Supplementary Aeronautical Data David Baker John Maurer Roger Costello
Use Case ARINC data Runway surface type: hard/soft
Commercial Data Provider Customer
Hello! I would like to purchase your ARINC data. I understand the runway is hard or soft; however, I would like to purchase information about what building material the runway is made of.
Runway surface type is not part of the ARINC data, but I can provide it separately
Runway surface type data ARINC data
Runway surface type data Supplementary data
Physically separate from the ARINC data Doesn't leverage the validation capabilities provided for the ARINC data Requires additional tools/applications Runway surface type data
XML Schema provides a mechanism for treating supplementary data in a standardized fashion
XML Schema mechanism: extension points ARINC data Extension point: a place where additional data not specified by the XML Schema can be inserted Supplementary Data
Extension points: hacker alert!
ARINC data ARINC data Hacker Data Supplementary Data ARINC data ARINC data Supplementary Data Data Provider Hacker Data Customer continued
ARINC data XML Schema Validator Valid! Data must be ... Data must be ... ... Hacker Data any data ARINC XML Schema
ARINC data XML Schema Validator Valid! That's not what we want! Data must be ... Data must be ... ... Hacker Data any data ARINC XML Schema
Risk mitigation: constrain the extension points Data must be ... Data must be ... ... Don't allow just any data any data ARINC XML Schema
Extension data must conform to a supplemental-data schema Data must be ... Data must be ... ... Data must be ... Data must be ... ... additional data must conform to ARINC XML Schema Supplemental-Data XML Schema
Data must be ... Data must be ... ... additional data must conform to ARINC data ARINC XML Schema Data must be ... Data must be ... ... Supplementary Data Supplemental-Data XML Schema Single, unified document containing ARINC plus supplemental data
Supplemental data is physically integrated with the ARINC data. Can leverage the validation capabilities provided for the ARINC data. No additional tools required. ARINC data Supplementary Data
ARINC data ARINC data Hacker Data Supplementary Data ARINC data ARINC data Supplementary Data Data Supplier Hacker Data Customer continued
Not valid! ARINC data XML Schema Validator Data must be ... Data must be ... ... Data must be ... Data must be ... ... Hacker Data Data Provider Supplemental-Data XML Schema additional data must conform to ARINC XML Schema
Not valid! ARINC data XML Schema Validator That is what we want! Data must be ... Data must be ... ... Data must be ... Data must be ... ... Hacker Data Data Provider Supplemental-Data XML Schema additional data must conform to ARINC XML Schema
One supplemental schema per customer Data must be ... Data must be ... ... Data must be ... Data must be ... ... Data must be ... Data must be ... ... . . . Supplemental-Data XML Schema for customer 1 Supplemental-Data XML Schema for customer 2 Supplemental-Data XML Schema for customer N
Data must be ... Data must be ... ... Supplemental-Data XML Schema for customer 1 Data must be ... Data must be ... ... Data must be ... Data must be ... ... Supplemental-Data XML Schema for customer 2 . . . additional data must conform to ARINC XML Schema Data must be ... Data must be ... ... Supplemental-Data XML Schema for customer N
Constraints on extension points 1. Extension data must conform to one of the supplemental-data schemas. 2. Extension data must validate against a supplemental-data schema. 3. The number of extension elements is constrained
Techy talk 1. Extension data must conform to one of the supplemental-data schemas. Extension data must come from an approved namespace. 2. Extension data must validate against a supplemental-data schema. 3. The number of extension elements is constrained
Techy talk (cont.) 1. Extension data must conform to one of the supplemental-data schemas. Extension data must come from an approved namespace. 2. Extension data must validate against a supplemental-data schema. XML instances are strictly validated. 3. The number of extension elements is constrained
Techy talk (cont.) 1. Extension data must conform to one of the supplemental-data schemas. Extension data must come from an approved namespace. 2. Extension data must validate against a supplemental-data schema. XML instances are strictly validated. 3. The number of extension elements is constrained. maxOccurs=N
<xs:any minOccurs="0" maxOccurs="5" namespace="http://www.customer1.org/extensions http://www. customer2.org/extensions ... http://www. customerN.org/extensions" processContents="strict" />
Extension data must belong to one of these namespaces <xs:any minOccurs="0" maxOccurs="5" namespace="http://www.customer1.org/extensions http://www.customer2.org/extensions ... http://www.customerN.org/extensions" processContents="strict" />
<xs:any minOccurs="0" maxOccurs="5" namespace="http://www.customer1.org/extensions http://www.customer2.org/extensions ... http://www.customerN.org/extensions" processContents="strict" /> Extension data must be processed strictly, i.e., must conform to a schema
The number of extension data items must be between 0 and 5 <xs:any minOccurs="0" maxOccurs="5" namespace="http://www.customer1.org/extensions http://www.customer2.org/extensions ... http://www.customerN.org/extensions" processContents="strict" />