Chapter 1.3 - How to use the specification Aerospace and Defence Industries Association of Europe 2016-12-31 GENERAL This chapter gives an overview of: - the structure and content of the specification - The basic production and delivery methods - the fundamental reading rules FIELD OF APPLICATION S1000D is an international specification, which is designed to cover technical publication and learning information in support of any platform, system or equipment project (air, sea, land vehicle, equipment or facilities, civil or military). The following aspects of technical publication and training information are described: - information generation (authoring) - management within the CSDB - publication generation - page-oriented and IETP - exchange of data modules, publications and training content packages - commenting The specification addresses two main delivery methods of technical publications and training content packages: - Data exchange - S1000D objects (data modules and supporting objects) delivery for further processing - Publishing - Delivery of publications and training content packages - Information ready to use Refer to Delivery methods for further details on the delivery methods. BASIC DEFINITIONS the Product Any platform, system or equipment (air, sea, land vehicle, equipment or facility, civil or military) Project The task to develop, maintain and dispose of the Product. technical publications Operational and maintenance documentation and data. Technical publications do not include design documentation (eg, design drawings or CAD models). learing information Information used in the development of training activities that facilitate learning and the development of new and existing skills. self-contained data module A data module which is ready to use without a need for any common information repository data modules. Refer to Self-contained vs CIR-dependent data modules. CIR-dependent data modules A data module which needs access to one or more Common Information Repository (CIR) data modules. Refer to Self-contained vs CIR-dependent data modules. SELF-CONTAINED VS CIR-DEPENDENT DATA MODULES There are two basic methods of production (authoring) and delivery (publishing) of data modules and publications: - Using self-contained data modules only. This is the basic method to deliver data modules. - Using common information repository data modules (eg, warnings, cautions, externalized applicability annotations) as a necessary part of the delivery. This method means that the "ordinary" data modules are delivered CIR-dependent. The CIR provides the ability to further optimize and reuse data. It does this by using: - CIR data modules. Refer to Chapter 4.13.1 - Optimizing and reuse - Common information repository concept. - Incremental updates of CIR data modules. Refer to Chapter 4.13.2 - Optimizing and reuse - Incremental update of CIR data modules. - Alternates. Refer to Chapter 4.13.3 - Optimizing and reuse - Alternates concept. - Container data modules. Refer to Chapter 4.13.4 - Optimizing and reuse - Container data module. NOTE The CIR concept can be implemented in the production process as "internal repositories" and thus not necessarily as CIR data modules. The delivery from a production environment using CIR data modules can be done in two ways: - Self contained data modules These data modules include all information needed to understand a description or fulfill the maintenance task. Data from the CIR data modules (eg, warnings, cautions, externalized applicability annotations), if used, are included (not linked) in the data modules to be delivered to the customer or end user. For example, if warnings, cautions and/or applicability CIR are used these must be included in the data modules to which they apply, if self-contained data modules are the deliverables. NOTE Only a limited set of data from the repository data modules can be included in the data modules. NOTE The CIR data modules can still be delivered together with the self-contained data modules as the repository data modules include useful additional/detailed information which cannot be accommodated in the data modules but used in an IETP. - CIR-dependent data modules These data modules are dependent on CIR data modules as pieces of information are "removed" or externalized into one or more CIR data modules prior to delivery to the customer or end user (or an IETP application). The customer, end user or the IETP application, resolves any links before use or during use of the IETP viewer/browser. The authoring rules differ between the two methods which are explained in the authoring chapters. Refer to Chap 3.9.5.2.1. When using CIR data modules certain information does not require authoring but would require referencing (linking) to the appropriate CIR data module. For example, the name of the support equipment being referenced (linked) to a CIR data module rather than being authored. Refer to Chapter 4.13.1 - Optimizing and reuse - Common information repository concept for details on the use of the CIR concept. Refer to Chapter 4.13.4 - Optimizing and reuse - Container data module for details on the use of the container concept. DELIVERY METHODS Data exchange The delivery method based on data exchange of S1000D objects (refer to Field of application) is used when the receiving organization has a CSDB and is expected to process the data and even include changes (eg, due to adaptation of the data modules to internal regulations and needs). The receiver can then produce another interchange package or produce the final ready-to-use publications or SCORM content package modules. Refer to Main delivery methods. Data exchange is done between two CDSB, a sender CSDB and a receiver CSDB. The exchange could be between a subcontractor and a prime, or between a contractor and a customer. The data exchange packages consist primarily of data modules and their associated illustrations and multimedia files. Publication modules, SCORM content package modules, and supporting files such as data dispatch notes and data management lists can also be exchanged. The interchange of transfer packages is done as described in Chapter 4.8 - Information management - Interchange of data modules. Delivery of ready-to-use publications or training content packages This method is used when the CSDB owner, contactor or customer, delivers a final ready-to-use product to the end user. It can be page-oriented publications delivered as paper publications in binders or electronic publications in PDF, the latter with some linking mechanisms. The deliverable can also be an IETP generated as described in Chapter 7.4.1 - Generation of publications - IETP, or a training related product. The latter could be used as SCORM, just-in-time training, instructor or student guides. [Main delivery methods] Delivery with and without CIR The exchange of data modules can be done based on self-contained or on CIR-dependent data modules. An interchange (transfer) package of CIR-dependent data modules must be accompanied with the relevant CIR. An interchange package of self-standing data modules does not necessarily include any CIR. However it can be useful to exchange CIR between partners (subcontractor and contractor) to have consistent data for supplies, support equipment, warnings and cautions. Delivery methods for technical publications - Detailed view shows the interchange of data between different CSDB. It also briefly shows the "data transfer" from a CSDB to an end user IETP via the neutral IETP-X format described in Chapter 7.4.1 - Generation of publications - IETP. [Delivery methods for technical publications - Detailed view] READING CONVENTIONS General Throughout the S1000D specific conventions are used to aid common understanding and to minimize duplication. These conventions are: Available for projects SNS and attribute values that are available for projects or organizations to give their own specific definitions. Not available for projects SNS, information codes and attribute values that are not available for projects or organizations to give their own specific definitions. Projects or organizations can apply for formal definitions by the normal CPF process. M Mandatory The attribute affected must be given in the data module and the required entries in the construct must be populated. (M) is used in some chapters to, for example, explain the use or presentation of specific data. O Optional The attribute affected can be omitted if a project or organization decides. (O) is used in some chapters to, for example, explain the use or presentation of specific data. (D) Default value The affected markup value is the default value. enterprise/company Enterprise is used as the generic term when a company and/or organization is referred to. Company is used as a synonym to enterprise when a business organization is referred to. The term manufacturer (Product manufacturer, equipment manufacturer, aircraft manufacturer) and supplier are used when needed in context only. These rules are being successively introduced in S1000D. must Mandatory to follow the given rules. name The name of a "thing" such as a part, a component, an assembly. Sometimes called description, nomenclature or designation. Name is used consistently throughout S1000D. can, could Options to be followed by project or organization decision. Permissible characters in codes and numbers Throughout the S1000D the following definitions on permissible characters (alphas and numbers) when used in codes (eg, data module codes, publication module codes, learn codes, learn event codes, data management lists) and numbers (eg, issue numbers) are given below. Alpha characters The code abbreviation is "A". The permissible characters are: - "A" thru "Z" in uppercase. It is recommended that the use of "I" and "O" is avoided. Numeric characters The code abbreviation is "X". The permissible characters are: - "0" thru "9" NOTE "NN" is frequently used to indicate a numerical sequence starting from "00" or "01". Details for the interpretation are given where used in the specification. Alphanumeric The code abbreviation is "Y". The permissible characters are: - "0" thru "9" - "A" thru "Z" in uppercase. It is recommended that the use of "I" and "O" is avoided. Specific alpha character values When an alpha character is given in a data module code that is intended to indicate a value, it is presented by underlining the character. For example, _A_ means the value of "A" and not an alpha character. "A" means an alpha character and not the value "A". Use of the alpha characters "I" and "O" _Business rule decision point BRDP-S1-00001 - USe of "I" and "O":_ - Decide whether and when to use the alpha characters "I" and "O". USE OF, AND APPLICATION FOR CAGE CODES The specification uses CAGE (Commercial and Government Entity) codes to uniquely identity enterprises and organizations. The values of some elements and attributes mandate that a registered CAGE code is used, for example, when using the identification extension in _DME_ and _PME_ (refer to Chap 4.12), when using the CAGE code based _ICN_ (refer to Chap 4.4), when using _data management lists_ (refer to Chap 4.5) and when commenting using the _Commenting Schema_ (refer to Chap 4.6). To perform a _file based transfer_ (refer to Chap 7.5.1) you also need a CAGE code. As it is essential to uniquely identify parts in many cases, the specification based the identification of those parts on the CAGE code. _Business rule decision point BRDP-S1-00002 - List of permitted CAGE codes and/or names to be used for the technical publication project:_ - Create a list of permitted CAGE codes and/or names of the enterprises. Enterprises and organizations that do not have a CAGE code, can apply for a code at their National Codification Bureau (NCB) or at: NSPA S2000M Administrator L-8325 CAPELLEN G.-D. Luxembourg Email: Spec2000M@nspa.nato.int ACRONYMS Throughout the S1000D common acronyms are used to aid understanding and to minimize duplication. These acronyms are: 2D Two Dimensional