The EDSCrate root element includes a required version attribute and is extended to include a sequence of a required CrateData element and an optional Signature element. The Signature element is governed by the W3C XML Signature Syntax and Processing Recommendation. The Signature element is the top-level element of the W3C XML Signature schema. It contains all of the information used to apply the digital signature to an EDS Crate. The Reference element within the SignedInfo element that is contained within the Signature element provides a reference to the value of the ID attribute in the CrateData element that is being signed. This reference enables the digital signature to be applied to the appropriate information. COMMENTARY The XML digital signature is not to be mistaken as signature of the CrateItems in the EDSCrate. Each distinct CrateItem may need to have its own integrity assurance mechanism applied. The security of the EDSCrate ensures that the crate has delivered what was placed in it but does not ensure that the CrateItems placed in the crate qualify to any given degree of integrity. The top level element that contains all information about the contents of the crate Version control is used in EDS XML Schema to enable efficient management of Schema revisions and to enable correct synchronization between the Schemas and the corresponding XML document instances. Version control in EDS Schema is managed through two mechanisms: 1. Use of the “version” attribute in the “xs:schema” element of the Schema to identify the version of the document based on the revisions incorporated from the previous version. The format of the attribute is N.nn where N is a number representing the Major version and nn is a number representing the Minor version. A major revision is one where an XML instance that is valid for one Schema version is no longer valid for the next Schema version. For example, an XML instance that is valid for Schema version 1.00 will no longer be valid for Schema version 2.00. Addition of a new mandatory data element would constitute a major revision. A minor revision is one where an XML instance that is valid for one Schema version will still be valid for the next Schema version. For example, an XML instance that is valid for Schema version 1.00 will still be valid for Schema version 1.01 or 1.27. Addition of new conditional data elements would constitute a minor revision. The Major and Minor numbers will increment accordingly with each revision of the Schema for the life of the Schema. 2. The version: attribute of the root element of each XML document instance will contain a numeric decimal value in the form of N.nn to identify the Major and Minor version of the schema to which the instance was designed. Describes the purpose of the EDS crate. Spec 2000 Model of Applicability Code (MOA) Identifies the aircraft model, engine model, or other product to which the EDS crate is applicable. This attribute is provided to facilitate processing of the crate. ModelReference shall not be used to support configuration management or effectivity. If ModelReference is used to depict an aircraft or engine model, it shall be consistent with the Model of Applicability Code (MOA) as defined in ATA Common Support Data Dictionary. Provides information about the sender and intended receiver of the EDSCrate, as well as additional information about the handling of the crate. Goups a set of parts that are functionally linked. Assembly element also provides descriptive information about how the parts relate to each other. Contains information about the items contained in the crate. It is used as a wrapper to provide structure to the list of crate items to facilitate processing. Uniquely identifies each instance of an EDS Crate. The id attribute shall be unique for each crate created by a source within a given crate expiration period. Suppliers have discretion for the content of the id attribute and may elect to include meaningful information such as supplier code and/or timestamp. Date and time the crate was assembled. The UTC date beyond which the sender no longer expects the crate to be used. The required AssemblyItem element defines a component of an Assembly. An indication that the related Part Number is certified or not The hardware attribute identifies the hardware unit or system, onto which the AssemblyItem is intended to be installed (e.g. 1TL1 for A380 ANSU). The software attribute identifies the software function identification of the AssemblyItem for a given hardware (for LSP: SLID for Boeing (Software Location ID), FIN (Functional Item Number) for Airbus). This attribute shall be consistent with the EIN element in the maintenance documentation (ATA Spec 2000). The name attribute defines the functional designation of the AssemblyItem. This name shall be consistent with nomenclature used in the maintenance documentation. Automated processes are not expected to enforce this requirement. The relatedPN attribute defines the part referred to by the AssemblyItem (e.g. a LSP or a MSP). Defines the part referred to by the AssemblyItem (e.g. a LSP or a MSP). Contains information about additional files that are associated with the AssemblyItem Identifies the type of assembly being described. A set of parts may be grouped in the following categories of assembly: • Kit, • Application, • Bundle, • Data, • Increment. A kit is a set of parts required for performing a task (e.g. modification or shop-loading). A typical example of a Kit is an SB Kit. Parts may constitute an Application (e.g. Flight Management function) and a set of Applications may constitute a Bundle (also known as Standard or Block Point). An assembly may regroup Parts dedicated to data update for a given Application (e.g. Flight Crew Operating Manual). An assembly may contain information for updating an existing part by using an increment. Defines the functional designation of the AssemblyData. This name shall be consistent with nomenclature used in the maintenance documentation. Automated processes are not expected to enforce this requirement. Defines the specific version of the AssemblyData. Together with the name attribute, it defines the complete identifier of the AssemblyData. Defines the date of release for the AssemblyData. Provides a hierarchical collection of information about the relationships between parts that are referenced in the crate. Provides a hierarchical collection of information about the relationships between parts that are referenced in the crate. Provides a hierarchical collection of information about the relationships between parts that are referenced in the crate. conformity Conformity item, i.e., an 8130 copyrightStatement Copyright information export Export control information functionalDescription Statement describing the function/purpose license Licensing information mediaLabel MSP label data (text and/or image) mediaBuildInstructions Instructions to build an MSP other Information that is not one of the aforementioned RelatedItemCategories redistribution Conditions and restrictions associated with redistribution of the crate item releaseNotes Description of changes in the release serviceBulletin Airplane modification instructions Each RelatedItem may be individually signed. If a RelatedItem is signed, the signature attribute shall list the fully qualified path name of the file containing the signature. Defines the functional designation of the RelatedItem. This name should be consistent with nomenclature used in the maintenance documentation. Automated processes are not expected to enforce this requirement. Describes the location of the RelatedItem presented in the form of a URI. The isIncluded attribute indicates if the RelatedItem is present in the crate. In cases where a RelatedItem is external to the crate, the isIncluded attribute would be set to “false” and the location attribute should be used to reference its external location. Describes each item in the crate. Contains information about additional files that are associated with the CrateItem. LSP-665 ARINC 665 loadable software part LSP-OTHER Other loadable software part MSP-665 Logical media set part MSP-OTHER BFP-665 Batch file part GSS Ground support software OTHER Other items Each CrateItem may be individually signed. If a CrateItem is signed, the signature attribute shall contain the fully qualified path name of the file that contains the signature. A partNumber for the CrateItem is provided by the creator of the CrateItem. This Report does not impose part number standards for CrateItems. Spec 2000 Manufacturer Code (MFR) identifies the manufacturer of the CrateItem. Under specifications of ARINC 665, a manufacturer’s code is included within the LSP part number. This attribute is included in anticipation of CrateItems where the source identifier is not otherwise evident. To be consistent with the part procurement process and standards, manufacturer shall be the Manufacturer Code (MFR) of the crate item creator as defined in the ATA Common Support Data Dictionary. The sender of an EDS crate may or may not be the manufacturer of the crate items being sent. Describes the location of the CrateItem in the EDSCrate relative to the CrateItem content, presented in the form of a URI. If the CrateItem isIncluded attribute =”true”, then the location shall be provided. The URI shall always identify a location within the crate as per the rule in section 4 that CrateItems must be located within the crate. • If the CrateItem category is LSP-665, the URI should be the location of the Load Header file. • If the CrateItem category is BFP-665, the URI should be the location of the Batch file. • If the CrateItem category is MSP-665, the URI should be the directory containing the Media files. • If the CrateItem category is LSP-OTHER, the URI should be the directory where the part files are located. • If the CrateItem category is MSP-OTHER, the URI should be the directory where the part files are located. • For all other CrateItem categories, the URI should be the location of the directory where the files are located. If the URI identified by the location attribute is set to a directory, then the CrateItem shall be comprised of all files inside the directory. CrateItems of category LSP and MSP should be placed in directories labeled with the correct part number. If the part number contains any illegal file system characters such as “/” or “\”, the illegal characters should be replaced with “-“. If the CrateItem location is a directory, the location URI should end with a trailing "/". Describes the name, title, description, or label of the CrateItem. Syntax, structure, or format applicable to the nomenclature attribute should be governed by standards or conventions applicable to the CrateItem and crateItemCategory. Indicates if the CrateItem is present in the crate. In cases where a RelatedItem is being delivered separately from a CrateItem, the isIncluded attribute would be set to “false” and the location attribute should not be used. ATA Spec 2000 Supplier Code (SPL) identifies the creator of the EDS Crate, not necessarily the provider of the parts contained in the crate. To be consistent with the part procurement process and standards, Supplier shall be the CAGE/NCAGE Code of the crate creator as defined in the ATA Common Support Data Dictionary. ATA Spec 2000 Customer Identification Code (CIC) identifies the intended recipient of the EDS crate. To be consistent with the part procurement process and standards, Customer shall be the Customer Code of the intended recipient as defined in the ATA Common Support Data Dictionary. Identifies instructions for processing the crate. Identifies the commercial reference number(s) used to track the orders/requests for the part(s) contained in the crate. Date and time stamp for when the crate is created. ATA Spec 2000 Customer Identification Code (CIC) ATA Spec 2000 Model of Applicability Code (MOA) Used to identify if the TrackingNumber is a PO Number, a Contract Number, a Work Order Number, or another tracking number. To be consistent with the part procurement process and standards and to enable automated tracking, TrackingNumber should be consistent with the ATA Common Support Data Dictionary. o If TrackingNumber is used to convey a PO Number, then it shall be consistent with the Customer Purchase Order Number (CPO) as defined in the ATA Common Support Data Dictionary. o If TrackingNumber is used to convey a Contract Number, then it shall be consistent with the Contract Number (CTN) as defined in the ATA Common Support Data Dictionary. o If TrackingNumber is used to convey a Work Order Number, then it shall be consistent with the Work Order Number (WON) as defined in the ATA Common Support Data Dictionary. o If TrackingNumber is used for any other purpose, or is not compatible with ATA standards, the "Other" format shall be used. If multiple PO_Numbers are provided, the schema does not support the relationships between each PO_Number and the parts in the crate. This information may be provided in the SpecialInstructions element or as related items in the crate. Special instructions for processing the crate. Used to reference more detailed instructions. ATA Spec 2000 Supplier Code (SPL)