XML schema to identify a data transfer package and its contents. Used to transfer retirement records from providers to OPM, and within OPM to various retirement systems. A data transfer package is a zipped file containing one manifest and one or more data transfer files. The manifest file must be names "manifest.xml". Each data transfer file contains one or more items, typically electronic retirements records and their associated metadata. Generally, there is only one data transfer file unless multiple files are needed to stay within technical file size limits. A set of items, e.g., retirement records in a data transfer file. An item, e.g., a record and its metadata. A set of instructions, e.g., cancellations of specific retirement records. An instruction, e.g., a cancellation of a previously submitted record and its metadata. Defines the contents of a data transfer package. The primary purpose is to enumerate all the files in a transfer, and to provide a definitive means of ensuring that all data is successfully transferred. A transfer package contains one document based on this schema and one or more content files with the actual data/records transferred. The document based on this schema should be named "manifest.xml". The manifest is designed to work with zipped and unzipped transfer packages. General information about this data transfer package. Unique package identifier assigned by the provider, which will be included in the transfer acknowledgment. If the package is retransmitted, the package ID should be the same as in the original transmission. Providers may use any convention for their identifier that conforms to the data type, such a a sequence number, date, or RFC4122 identifier. A unique identifier assigned by the provider that may be used to associate a group of transfer packages, e.g., to send a single very large extract as multiple data transfer packages. The type of package. If type is "test", the package will be received, validated, acknowledged, and discarded. When the transfer package was created. May be used by providers to help determine what data needs to be re-extracted if a transfer package is dropped anywhere in the process. Identifies the agency providing this data or (for SSCs) the agency for whom the data is being provided. Used to determine where to send transfer acknowledgments and to enable providers to view status for their (and only their) submissions. A textual description of the contents of the transfer package. Included in the transfer acknowledgment, and displayed in the data transfer package receipt history page. Used as needed by providers for their own convenience or to communicate the contents of the package to the recipient. Strongly recommended to contain standardized information, such as associated pay period, to aid problem resolution in the event there is a problem with a particular package. The provider-assigned version number for the extract process and software, for example "1.2". Used by the recipient in conjunction with the schema version to apply the correct transformation and validation rules. Used by the provider to determine in the future what records might need to be re-extracted. Note: we currently assume all records in a given data transfer package are extracted using the same process. The OPM-assigned version identifier for the record schema used for the extract. Used by the recipient to apply the correct data validations. Note that different extract processes may use the same schema version in different ways, e.g., which optional fields are populated. Note: we currently assume all records in a given data transfer package are extracted using the same target schema. A reference to a file that is part of this transfer package. Used to ensure that all files in the transfer are processed. The names of the files in the transfer package are not significant, but must be unique. The location of a content file. Currently, only file path+name relative to the manifest document is allowed.