The file's text, extracted by GovTribe without its formatting.
AF Business Rules
| Project Business Rules for Program: | | Insert project/program name here. | 0 |
| BRPD# | Business Rule Decision Point Title/Definition | Project Decision | Additional Comments |
| S1000D, Issue 4.1, Chapter 1.3 - How to use the specification | | | |
| BRDP-S1-00001 | Use of "I" and "O": | | |
Decide whether and when to use the alpha characters "I" and "O".
| Additional info: This decision is referring to use of those characters in data module codes, publication module codes, and scorm package codes. | The use of alpha characters "I" and "O" is allowed as appropriate. However, authors must ensure fonts used in the publication allow for the end user to easily distinguish "I" and "O" from "1" and "0". | "I" and "O" Not currently used |
| BRDP-S1-00002 | List of permitted CAGE codes and/or names of the originator companies to be used for the technical publications: |
| Create a list of permitted CAGE codes and/or names of the originator companies. | The project shall create and maintain a list of permitted commercial and government entity (CAGE) codes and/or names of the originator companies. This list will be created after contract award. | N/A |
| S1000D, Issue 4.1, Chapter 2.5.1 - Business rules - Categories and layers | |
| BRDP-S1-00003 | Issue of S1000D to be used: |
| Decide which issue or issues of S1000D to be used. | S1000D issue 4.1 shall be used. | Use of MIL-STD-1808 for SSSN numbering |
| BRDP-S1-00004 | Information sets to be used: |
| Decide which information sets, given in S1000D and/or project specific, to be used. | The selected information sets (i.e. the technical content requirements to be covered) are defined in the TMSS listed in the table at the end of this spreadsheet. These information sets are to be used in place of the information sets defined in chapter 5 of S1000D. | 0 |
| BRDP-S1-00005 | Publications to be produced: |
| Decide which publications to be produced. | The program shall coordinate with the contractor after contract award and collaborate in the contractor's creation of the Data Management Requirement List (DMRL). The DMRL shall list all data modules and publications desired by the program to be produced and delivered by the contractor. | Contractor will not be required to create a DMRL. However, if new DM's are created, the DM's will be numbered accordingly and be added to the DMRL. |
| BRDP-S1-00006 | Schemas to be used: |
| Decide which Schemas to be used and in which information set they are to be used. | Only the promulgated S1000D schemas for issue 4.1, available at http://www.s1000d.org shall be used. The contractor shall use the schema that best fits the technical data being authored (i.e. descriptive data uses the descript schema, troubleshooting data uses the fault schema, etc.) with final approval by the program. | |
| BRDP-S1-00007 | Use of optional elements and attributes: |
| Decide whether and how to use each optional element and attribute in its structural context. | Optional elements and attributes shall be used as necessary to support program functionality requirements and as dictated by Air Force and project business rules. | For example: Underlined used to indicating lower case letter in wiring diagrams or schematics. |
| BRDP-S1-00008 | Possible deliverables: |
Decide on the possible deliverables, such as:
- S1000D objects (eg, data modules, publication modules, illustration sheets and multimedia objects, data management lists) using file based transfer.
| - Page-oriented publications and/or interactive electronic technical publications. | All deliverables are listed in the TMCR. | |
| BRDP-S1-00009 | Frequency of data exchanges: |
| Decide on the frequency of data exchanges. | Frequency of data exchanges are specified in the TMCR as part of the In-Process Review (IPR) and delivery schedule. | |
| S1000D Chapter 3.4 - Information generation - Zoning and access | |
| BRDP-S1-00010 | Zone and access point identification system: |
| Decide whether to use a zoning and access identification system. | A zoning and access identification system shall be used. | |
| BRDP-S1-00011 | Method for zoning and identifying access points: |
| Decide which method to use for zoning and identifying access points. | The contractor shall select the most appropriate method for zoning and identifying access points by following S1000D guidelines (see chapter 3.4.1 in S1000D). The program shall give final approval of the method selected. | |
| S1000D Chapter 3.6 - Information generation - Security and data restrictions | |
| BRDP-S1-00012 | Define security classification values and terms (attribute securityClassification): |
Decide which values to use for the attribute securityClassification and allocate suitable definitions. Refer to Chap 3.9.6.1. The following values for the attribute securityClassification shall be used:
- 01 unclassified
- 02 not allowed
- 03 confidential
- 04 secret
- 05 top secret
- 06-50 - not allowed
- 51-99 not allowed BRDP-S1-00013 Use and markings of security classifications (attribute securityClassification):
| Determine how the security classifications will be used. | Security classifications shall be marked in accordance with DoD information security program instructions/directives. | |
| BRDP-S1-00014 | Application of caveats: |
| Determine if the policies that apply to security marking, instructions, etc, and how those markings are required to be applied within the given project. | The application of caveats shall be in accordance with DoD information security program instructions/directives. Neither commercial classification nor national caveat shall be used as an alternative to security classification. | |
| BRDP-S1-00015 | Retention of security classifications: |
| Decide on the retention of security classifications. | The retention of security classification markings shall be in accordance with DoD information security program instructions/directives. | |
| BRDP-S1-00016 | Presentation of security classifications: |
| Decide on how the security classifications will be marked and/or indicated. | Security classifications shall be marked in accordance with DoD information security program instructions/directives. | |
| S1000D Chapter 3.7 - Information generation - Quality assurance | |
| BRDP-S1-00017 | Rules for QA: |
Decide on the rules for QA of data modules and deliverables. Final delivery shall not include unverified data modules.
Draft data modules may only be exchanged for the purposes of validation/verification and for other purposes expressly specified by the project.
Projects shall follow all quality assurance, certification, and verification requirements detailed in TO 00-5-3.
The contractor shall develop and present agreeable rules for QA of data modules and deliverables.
BRDP-S1-00018 Rules for first and second verification:
Decide on the rules for first and second verification. For example, such a rule might be that all data modules that have a safety related procedure must have first verification carried out "On object". The contractor is responsible for the end result of the TO development process; that is, for delivery of adequate, safe, current and accurate TOs which conform to government requirements. The contractor shall present a detailed certification process that will conform to these requirements.
First verification shall be considered equivalent to contractor certification as detailed in TO 00-5-3.
Second verification shall be considered equivalent to USAF verification as detailed in TO 00-5-3.
BRDP-S1-00019 Review cycle process:
| Decide on the review cycle processes and procedures. | The review cycle process is specified in the TMCR. | TMCR specifies a 50, 75 and 100 percent review of new DMs |
| S1000D Chapter 3.9.1 - Authoring - General writing rules | |
| BRDP-S1-00020 | Specify the language: |
| Decide which language to use for producing data modules. | Data modules shall be authored using Standard American English. | |
| BRDP-S1-00021 | Use of ASD Simplified Technical English: |
| Decide whether to use ASD-STE100® when producing data modules in English. | Do not use ASD Simplified Technical English unless otherwise specified by the program. | |
| BRDP-S1-00022 | Standard dictionary: |
| Decide which standard dictionary to use for producing data modules. | The U.S. Government Printing Office Style Manual (GP 1.23/4:ST 9/2008) shall be used as a general guide for standard American English usage and punctuation. To determine and convey the proper spelling and meaning of words, the current version of Webster's International Dictionary of the English Language shall be used. | |
| BRDP-S1-00023 | Use of a terminology database or glossary: |
| Decide whether to use a terminology database or a glossary. If used, agree on its content and management. | The contractor shall establish a terminology database/glossary to ensure that terminology is used consistently. Projects shall make use of Joint publication 1-02 for military terms and abbreviations and ASME Y14.38 for engineering terms and abbreviations. | |
| BRDP-S1-00024 | Use of a standard list of abbreviations: |
| Decide whether to use a standard list of abbreviations. If used, agree on its content and management. | The contractor shall establish a standard list of acronyms and abbreviations. Projects shall make use of Joint publication 1-02 for military terms and abbreviations and ASME Y14.38 for engineering terms and abbreviations. | |
| BRDP-S1-00025 | Units of measurement: |
| Decide what unit of measurement to use for primary and secondary units. | Projects shall use U.S. customary units (ounces, pounds, gallons, inches, feet, knots, miles, etc.) as the standard units of measurement. A secondary unit of measurement may be used when approved by the program. | |
| BRDP-S1-00026 | Highlighting text: |
| Decide on which method to be used to emphasize text. | Projects shall indicate the emphasis of content by setting the value of the attribute emphasisType of the element <emphasis> to "em51", which shall be presented as bold/italic. No other values are permitted. | |
| S1000D Chapter 3.9.2 - Authoring - Illustration rules and multimedia | |
| BRDP-S1-00027 | Need of printable data: |
| Decide which parts of the documentation (data modules and publications including IETP) need to be printable. | Printing requirements are listed under the functionality requirements worksheet and publications required are listed as part of the DMRL. | |
| S1000D Chapter 3.9.2.1 - Illustration rules and multimedia - Illustrations, General | |
| BRDP-S1-00028 | Engineering numbers and revision status within the illustration reproduction area: |
| Decide if schematics derived from engineering drawings include the original drawing number and revision status within the illustration reproduction area. | The contractor may decide if schematics derived from engineering drawings include the original drawing number and revision status within the illustration reproduction area. | |
| BRDP-S1-00029 | Use of color in the final deliverable: |
| Decide whether to use color in the final deliverable. | The contractor may use color in the final deliverable if approved by the program. If colors are used, they shall conform to the S1000D standard color palette and their use shall remain consistent across the project. | |
| S1000D Chapter 3.9.3 - Authoring - Warnings, cautions and notes | |
| BRDP-S1-00030 | Use of general warnings, cautions and notes as separate data modules: |
Decide whether to produce general warnings, cautions and notes in separate descriptive data modules. Warnings and cautions shall not be used in descriptive data, except in the case of a publication’s safety summary (e.g., IC 012J).
As applicable the contractor shall deliver one or more descriptive data modules containing a publication's safety summary, which shall include general precautions applicable to the safety and health exposures found in the technical manual. Guidance for the authoring of safety summaries is found in MIL-STD-38784.
Delivered data modules with procedures that require warnings or cautions shall not reference warnings or cautions in a separate data module. Delivered data modules shall contain the complete warning or caution content.
BRDP-S1-00031 Use of warning and/or caution collections:
| Decide whether to use warning and/or caution collections, internal or external. | The use of the element <warningsAndCautions> (warning and caution collections) is disallowed. | |
| BRDP-S1-00032 | Use of the attribute vitalWarningFlag: |
| Decide whether and how to use the attribute vitalWarningFlag. | Use of the attribute vitalWarningFlag is prohibited. | |
| BRDP-S1-00033 | Use of the attribute warningType: |
| Decide whether and how to use the attribute warningType. | Use of the attribute warningType is prohibited. | |
| BRDP-S1-00034 | Use of the attribute cautionType: |
| Decide whether and how to use the attribute cautionType. | Use of the attribute cautionType is prohibited. | |
| BRDP-S1-00035 | Use of the attribute noteType: |
| Decide whether and how to use the attribute noteType. | Use of the attribute noteType is prohibited. | |
| S1000D Chapter 3.9.4 - Authoring - Front matter | |
| BRDP-S1-00036 | Presentation of the issue number and the inwork number on the title page: |
| Decide whether to present the issue number with or without the inwork number on the title page. | The presentation of an inwork number on the title page of a final delivered publication is prohibited. | |
| BRDP-S1-00037 | Use of LOEP or LOEDM: |
| Decide whether the use of LOEP or LOEDM. | Publications shall have a List of Effective Data Modules (LOEDM). Publications shall not have a List of Effective Pages (LOEP). | |
| BRDP-S1-00038 | Presentation of the issue date or the issue number in the LOEP: |
| Decide whether to present the issue date or the issue number (with or without inwork number) for the LOEP entries. | Publications shall not have a LOEP. | |
| BRDP-S1-00039 | Presentation of applicability information in the LOEP: |
| Decide whether to present the applicability information for the LOEP entries. | Publications shall not have a LOEP. | |
| BRDP-S1-00040 | Presentation of the issue date or the issue number in the LOEDM: |
| Decide whether to present the issue date or the issue number (with or without inwork number) for the LOEDM entries. | The LOEDM shall present, at a minimum, the data module code, the data module title, and issue number. The inwork number shall not be presented. | Example: DMC-HH60-G-E31-50-0000-00001-340A-A_003-00_EN-US.XML_INSTRUMENT_FAULT_ ISOLATION_PROCEDURES_DDMMYYYY |
| BRDP-S1-00041 | Presentation of applicability information in the LOEDM: |
| Decide whether to present the applicability information for the LOEDM entries. | The program shall work with the contractor to ensure the program's overall vision of applicability use is understood and implemented properly. | |
| BRDP-S1-00042 | Use of Highlights with updating instructions: |
| Decide whether to use Highlights with updating instructions or not. | The use of "Highlights with updating instructions" data module is prohibited. | |
| BRDP-S1-00043 | Presentation of the issue date or the issue number in the Highlights: |
| Decide whether to present the issue date or the issue number (with or without inwork number) for the Highlights entries. | Entries in the Highlights data module shall be presented with the issue number, but without the inwork number or issue date. | |
| BRDP-S1-00044 | Presentation of applicability information for the Highlights: |
| Decide whether to present the applicability information for the Highlights entries. | The program shall work with the contractor to ensure the program's overall vision of applicability use is understood and implemented properly. | |
| BRDP-S1-00045 | Presentation of the issue date and the issue number in the TOC: |
| Decide whether to present the issue date and/or the issue number (with or without inwork number) that apply to the TOC entries. | TOC entries shall contain issue numbers; issue dates and inwork numbers shall be excluded. | N/A |
| BRDP-S1-00046 | Use of linear or hierarchically subdivided TOC: |
| Decide whether to use a linear or a hierarchically subdivided TOC. | TOCs shall be hierarchically subdivided. | N/A |
| S1000D Chapter 3.9.5.1 - Data modules - Identification and status section | |
| BRDP-S1-00047 | Country and language codes: |
Decide on the country and language codes to use, and apply them consistently across the project. The value of the attribute languageIsoCode shall be set to English ("en") or, if Simplified Technical English is used, ("sx"), and the value of the attribute countryIsoCode shall be set to the United States ("US").
BRDP-S1-00048 Exchange of draft data modules:
| Decide whether the project will allow the exchange of draft data modules. | Draft data modules may only be exchanged for the purposes of validation/verification and for other purposes expressly specified by the project. | |
| BRDP-S1-00049 | Definition of the issue date: |
Decide on the definition of the issue date. This can be, for example, the input date (ie, the release to CSDB date), or the cut-off date for the delivery, etc. For publication modules, the issue date shall be the cutoff date from which no further changes are permitted (i.e. the publication date as defined in MIL-STD-38784).
For DMRL modules, the issue date shall be the date of delivery.
For all other data modules, issue date shall be the input date (i.e. the date it was last updated and issued to the CSDB).
BRDP-S1-00050 Source of the technical names:
| Decide on the source of the technical names and use them consistently across the project. In all cases, the technical name must reflect the item represented by the SNS. | The contractor shall compile a list of all technical names to be used in the project with final approval residing with the program. | |
| BRDP-S1-00051 | Rules for the information names: |
| Decide on which information codes apply to the project. | Information codes shall be restricted to those in the Joint Service information code list. The contractor shall apply the information code that best fits the content of the data module. If new information code variants are needed, the program shall submit the code, information name, and definition to the AF representative to the Joint Service IETM Technology Working Group (JSITWG). | Information codes will be provided by the TOMA |
| BRDP-S1-00052 | Allocation of the information codes and the information names: |
Decide on which information codes and associated information names to be used, and assign a Schema to be used for each information code. Information codes shall be restricted to those in the Joint Service information code list. The contractor shall apply the information code that best fits the content of the data module. If new information code variants are needed, the program shall submit the code, information name, and definition to the AF representative to the Joint Service IETM Technology Working Group (JSITWG).
| The contractor shall use the schema that best fits the data being authored (i.e. do not use the descript schema to author procedural data). The DMRL shall list the schema used for each data module listed with final approval residing with the program. | Information codes will be provided by the TOMA | |
| BRDP-S1-00053 | Data module change/revised ratio: |
| Decide on the threshold that a data module is considered revised rather than changed. | A data module shall be considered "revised" when 70% or more of the information has been changed. | N/A for DVES |
| BRDP-S1-00054 | Use and definitions of the attributes commercialClassification and caveat: |
Decide on the use and definitions of the attributes commercialClassification and caveat. Use of the attribute commercialClassification is prohibited.
The appropriate DoD information security program instructions/directives shall be followed for the proper use of caveats.
BRDP-S1-00055 Priorities and relationships of the security attributes securityClassification, commercialClassification and caveat:
| Decide on the priorities and relationships between the attributes securityClassification, commercialClassification and caveat if they are used. | Commercial classification shall not be used. The appropriate DoD information security program instructions/directives shall be followed for the proper use of caveats and security classifications. | |
| BRDP-S1-00056 | Use of the element <dataRestrictions>: |
| Decide whether to include data restriction information. | The optional element <dataRestrictions> shall be used for all publication modules and data modules. | N/A |
| BRDP-S1-00057 | Use of the attribute applicability in the element <dataRestrictions>: |
| Decide whether to differentiate data restrictions information based on Product configuration. | The program shall work with the contractor to ensure the program's overall vision of applicability use is understood and implemented properly. In all cases, follow the appropriate DoD information security program instructions/directives. | N/A |
| BRDP-S1-00058 | Use of the element <restrictionInstructions>: |
Decide whether to include export controls, handling, destruction notices and disclosure instructions. Export controls, handling, destruction notices and disclosure instructions shall be included as dictated by the appropriate DoD information security program instructions/directives.
| The child elements of <restrictionInstructions> shall be used as directed by the applicable business rules for each child element. | N/A | |
| BRDP-S1-00059 | Use of the element <dataDistribution>: |
| Decide on the distribution information contained in the element <dataDistribution>. | The element <dataDistribution> within <restrictionInstructions> shall contain the appropriate distribution statement as selected from DOD information security program instructions/directives. | N/A |
| BRDP-S1-00060 | Use of the element <dataHandling>: |
| Decide whether and how to use the element <dataHandling>. For example, the handling requirements and procedures that must be applied to a data module. | Because handling information is typically presented as part of the export control notice and the destruction notice, the element <dataHandling> within | |
| <restrictionInstructions> shall not be used. | N/A | |
| BRDP-S1-00061 | Use of the element <dataDestruction>: |
| Decide whether to use the element <dataDestruction> and how to use it. For example, the appropriate extent of destruction instructions that must be applied to a data module. | The element <dataDestruction> within <restrictionInstructions> shall contain the appropriate destruction notice as specified in DOD information security program instructions/directives. | N/A |
| BRDP-S1-00062 | Use of the element <dataDisclosure>: |
| Decide whether and how to use the element <dataDisclosure>. For example, the requirements that must be applied to a data module with regard to disclosure instructions. | Because disclosure information is typically presented as part of the export control notice and the destruction notice, the element <dataDisclosure> within <restrictionInstructions> shall not be used. | N/A |
| BRDP-S1-00063 | Use of the element <supersedure>: |
| Decide whether to use the element <supersedure> and how to use it. For example, the requirements that must be applied to a data module with regard to supersedure notices. | Supersedure notices shall only be used when necessary at a publication level and not at the data module level. When a publication supersedes another publication, a supersedure notice (element <supersedure> in publication modules) shall include the publication number and date, and if applicable, the issue/revision number and issue date of the superseded publication. Use of the element <supersedure> in data modules is prohibited. | N/A |
| BRDP-S1-00064 | Use of the element <restrictionInfo>: |
Decide whether and how to use the element <restrictionInfo>. For example, the content and extent of restriction information to include in a data module. Restriction information shall be included as dictated by the appropriate DoD information security program instructions/directives.
| The child elements of <restrictionInfo> shall be used as directed by the applicable business rules for each child element. | N/A | |
| BRDP-S1-00065 | Use of the element <copyright> and source of copyright information: |
Decide whether and how to use the element <copyright>. Any copyright information must be obtained from the relevant authority. Publications should not contain copyrighted material except as specified in the Federal Acquisition Regulations (FAR) and Defense Federal Acquisition Regulation (DFAR) Supplement. When copyrighted or proprietary material is included in a publication, the author shall obtain prior written permission from the copyright owner or authorized agent for its use. The signed, written permission shall contain a statement declaring whether or not a copyright credit line is required. When a copyright credit line is required, the following information shall appear in the <copyright> element of the data module:
"This document contains copyright or proprietary materials. Infringement of copyright or proprietary material may violate existing Federal laws and statutes and result in criminal penalties, imprisonment, or removal from office."
BRDP-S1-00066 Method of populating copyright information (in each data module or in a consolidated data module):
| Decide whether to populate copyright information in each data module or whether to cross-reference to a copyright data module. | If it is necessary to include copyright information, the copyright information shall not be contained in a separate copyright data module. The copyright information shall be contained within each applicable data module. | |
| BRDP-S1-00067 | Use of the element <policyStatement>: |
| Decide whether to use the element <policyStatement>. | If required, the element <policyStatement> within <restrictionInfo> within <dataRestrictions> within <pmStatus> shall contain the classification source and reason for classification for the publication as specified in DOD information security program instructions/directives. | N/A |
| BRDP-S1-00068 | Use of the element <dataConds>: |
| Decide whether to use the element <dataConds>. | The element <dataConds> within <restrictionInfo> within <dataRestrictions> within <pmStatus> shall contain declassification and downgrade instructions for the publication as specified in DOD information security program instructions/directives. | N/A |
| BRDP-S1-00069 | Use of the element <logo>: |
| Decide whether to use the element <logo> and how it should be used at presentation. | The use of the element <logo> is prohibited. | |
| BRDP-S1-00070 | Use of the element <enterpriseName> and/or the attribute enterpriseCode for the responsible partner company: |
| Decide whether to use the element <enterpriseName> and/or the attribute enterpriseCode to capture the name and CAGE code respectively, of the responsible partner company. If the name is used it must be done consistently and be mandatory for the project. | Both the element <enterpriseName> and the attribute enterpriseCode shall be populated consistently throughout the project. The enterpriseCode attribute shall not be used when the CAGE code is unavailable or when used on parent publication modules where only <enterpriseName> is used to display the publication issuing authority. | |
| BRDP-S1-00071 | Use of the element <enterpriseName> and/or the attribute enterpriseCode for the responsible originator: |
| Decide whether to use the element <enterpriseName> and/or the attribute enterpriseCode to capture the name and CAGE code respectively, of the originator. If the name is used it must be done consistently and be mandatory for the project. | Both the element <enterpriseName> and the attribute enterpriseCode shall be populated consistently throughout the project. The enterpriseCode attribute shall not be used when the CAGE code is unavailable. | |
| BRDP-S1-00072 | Use of the element <techStandard>: |
| Decide whether to use the element <techStandard>. | Use of the element <techStandard> is prohibited. | |
| BRDP-S1-00073 | Use of the element <authorityInfo>: |
| Decide whether and how to use the element <authorityInfo>. | Use of the parent element <techStandard> is prohibited. | |
| BRDP-S1-00074 | Use of the element <techPubBase>: |
| Decide whether and how to use the element <techPubBase>. If used, agree on acceptable values for the publication baseline and where they are derived from. | Use of the parent element <techStandard> is prohibited. | |
| BRDP-S1-00075 | Use of the element <authorityNotes>: |
| Decide how to use the element <authorityNotes>. | Use of the parent element <techStandard> is prohibited. | |
| BRDP-S1-00076 | Use of the attribute applicRefId of the element <qualityAssurance>: |
| Decide whether to use attribute applicRefId on QA information. | Applicability shall not be used on QA information. QA applies to the entire data module. | |
| BRDP-S1-00077 | Exchange of draft data modules: |
| Decide whether the project will allow the exchange of draft data modules. | Draft data modules may only be exchanged for the purposes of validation/verification and for other purposes expressly specified by the project. | |
| BRDP-S1-00078 | Use of the element <systemBreakdownCode>: |
| Decide whether to use the element <systemBreakdownCode>. If used, its use must be consistent across the project. | When a data module is associated with a Work Unit Code (WUC), projects shall store the WUC in the element <systemBreakdownCode>. When a data module is associated with multiple WUCs, projects shall store each WUC in a separate occurrence of the element <systemBreakdownCode>. | |
| BRDP-S1-00079 | Use of the element <functionalItemCode>: |
| Decide whether to use element <functionalItemCode>. If used, its use must be consistent across the project. | Use of the element <functionalItemCode> is prohibited. | |
| BRDP-S1-00080 | Use of the element <functionalItemRef>: |
Decide whether to use the element <functionalItemRef>. If used, its use must be consistent across the project. Reference designators in IPD data modules shall be identified by using the element <functionalItemRef> with the attribute functionalItemNumber. Use of the element <functionalItemRef> in the data module status section is prohibited.
BRDP-S1-00081 Use of the attribute functionalItemNumber of the element <functionalItemRef>:
Decide how to populate the attribute functionalItemNumber of the element <functionalItemRef> when this element is used. Reference designators in IPD data modules shall be identified by using the element <functionalItemRef> with the attribute functionalItemNumber. Use of the element <functionalItemRef> in the data module status section is prohibited.
BRDP-S1-00082 Use of the attribute manufacturerCodeValue of the element <functionalItemRef>:
| Decide whether and how to use the attribute manufacturerCodeValue of the element <functionItemRef>. If used, the element must be populated consistently across the project. | The contractor shall use as needed to support the technical content requirements listed in the chosen information sets. | |
| BRDP-S1-00083 | Use of the element <productSafety>: |
| Decide whether to use the element <productSafety> and under what circumstances. | Use of the element <productSafety> is prohibited. | |
| BRDP-S1-00084 | Values for the attribute safetyLabel: |
| Define the values to use for the attribute safetyLabel. | Use of the attribute safetyLabel is prohibited. | |
| BRDP-S1-00085 | Use of the element <remarks> in the element <dmStatus>: |
| Decide whether to use the element <remarks>. If used, its use must be defined in the project business rules and guidance given. | Use the element <remarks> is prohibited. | |
| BRDP-S1-00086 | Use of the attribute applicRefId of the element <remarks> within the element <dmStatus>: |
| Decide whether and how to use the attribute applicRefId of the element <remarks> in the element <dmStatus>. The element <remarks> can contain remarks, which can be differentiated based on Product configuration. | Use the element <remarks> is prohibited. | |
| S1000D Chapter 3.9.5.1.1 - Identification and status section - Export control | |
| BRDP-S1-00087 | Use of export control: |
| Decide whether export control regulations apply. | If applicable, export control regulations shall apply in accordance with DOD information security program instructions/directives. | N/A |
| BRDP-S1-00088 | Content of export control details: |
Decide on the requirements and procedures that must be applied to a data module regarding export controls. The export control statement (using the element <exportControl> within <restrictionInstructions>) shall be as directed by DOD information security program instructions/directives.
| When applicable, the export control statement shall contain the following text: "This document contains technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C., Sec. 2751 et seq.) or the Export Administration Act of 1979, as amended (Title 50, U.S.C., App. 2401, et seq.). Violation of these export-control laws is subject to severe criminal penalties. Dissemination of this document is controlled under DoD Directive 5230.25." The text shall be preceded by the label "WARNING" followed by either a colon or a dash (surrounded by spaces), consistent with other similar labels (e.g., "DESTRUCTION NOTICE - "). | N/A | |
| S1000D Chapter 3.9.5.2.1.1 - Common constructs - Change marking | |
| BRDP-S1-00089 | Standard wording for reasons for update: |
Decide standard reason for update sentences to be used. Reason for update can be used to automatically generate a highlights data module. Normally, a project will mandate its use from issue "002" upwards. Examples are:
- Revised to incorporate modification XYZ
| - Deleted. Data module no longer required | The contractor will ensure reason for updates include a brief statement indicating why content was changed. They will develop a standard approach to forming these statements with final approval residing with the program. The reason for update shall only be displayed to the user in the highlights pages/screens. | N/A |
| BRDP-S1-00090 | Use of reason for update in conjunction with the production process: |
Decide whether the element <reasonForUpdate> is used during the production process. Reason for update (<reasonForUpdate>) shall be used (for all issues after 001) and it shall include the reasons for updates for each changed data module in the latest change package. It shall also include textual references to all appropriate reason for update documentation (e.g., engineering change proposals).
| The cross-reference method for linking changes to reasons for update, using the attribute reasonForUpdateRefIds, shall be used in all cases when a data module or publication module is updated. | N/A | |
| BRDP-S1-00091 | Use of applicability information: |
Decide whether it is permissible to differentiate reasons for update based on Product configuration. Applicability shall be used on reason for update to reflect different configurations.
| The program shall work with the contractor to ensure the program's overall vision of applicability use is understood and implemented properly. | N/A | |
| BRDP-S1-00092 | Use of change marks for tables: |
| Decide whether and how to use change marks for tables. | Change marks for tables shall be used. The display of change marks and authoring of change markup is further detailed in MIL-STD-3048 and S1000D. | |
| BRDP-S1-00093 | Use of change marks for figures: |
| Decide whether and how to use change marks for figures. | Change marks for figures shall be used. The display of change marks and authoring of change markup is further detailed in MIL-STD-3048 and S1000D. | |
| S1000D Chapter 3.9.5.2.1.2 - Common constructs - Referencing | |
| BRDP-S1-00094 | Extent of cross-referencing: |
Decide on the extent of cross-referencing within data modules and the methods used for populating the various attributes. The element <internalRef> shall be used for all internal references.
The use of the attribute id is required on the following items:
a. <figure>
b. <graphic>
c. <table>
d. <levelledPara>
e. <proceduralStep> and <crewDrillStep>
f. <multimedia>
g. <multimediaObject>
The id attribute values shall be unique within a data module.
At a minimum, the attribute id shall be used for elements that are the destination of an internal cross-reference.
List items shall not be the destination of a link.
BRDP-S1-00095 Use of the element <internalRef> in titles:
| Use of the element <internalRef> in titles is strongly discouraged. However, decide whether to use cross-references in titles. | Titles shall not contain references. | |
| BRDP-S1-00096 | Use of the attribute targetTitle: |
Decide whether to use the attribute targetTitle.
| When used (populated), it is a tooltip in a viewer application. | The attribute targetTitle shall be used to present appropriate tooltips to the user. | |
| BRDP-S1-00097 | Presentation of the target titles in cross-references: |
Decide whether to present the target titles given in the element <title>.
| Note: Presentation of the titles depends on the presentation system and its settings. | Do not present the target title of the cross-reference. The generated identifiers are based on the target element as specified in MIL-STD-3048. | |
| BRDP-S1-00098 | Use of the textual content of the element <internalRef> in cross-references: |
Decide whether to use the textual content of the element <internalRef>.
| When used (populated), it must be presented. | The use of textual content of the element <internalRef> is prohibited. | |
| BRDP-S1-00099 | Use of the "identifiers" given in the elements <reqSupportEquips>, <reqSupplies>, <reqSpares> or <workLocation>: |
Decide whether to use any of the "identifiers" given in the elements <reqSupportEquips>, <reqSupplies>, <reqSpares> or <workLocation> as the presented link (textual content of the element <internalRef>), or as a tooltip in a viewer application (value of the attribute targetTitle).
| Note: The "identifiers can be derived from the content of the child elements or the attributes of the four elements. | Do not use the alternate identifiers. The generated identifiers are based on the target element as specified in MIL-STD-3048. | |
| BRDP-S1-00100 | Use of the attribute internalRefTargetType: |
| Decide whether to use the attribute internalRefTargetType, which values to use and allocate suitable definitions to the values. Refer to Chap 3.9.6.1. | The use of the attribute internalRefTargetType is prohibited. | |
| BRDP-S1-00101 | Define the format of the cross-reference attributes id and internalRefId: |
Decide whether the values of the cross-reference attributes id and internalRefId must be prefixed by alpha characters that identify the type of the target element. Example:
• Structure: Prefix followed by a hyphen and a four digit number to make it unique within the data module (eg, "par-0001").
• Prefixes:
− "fig" for figures and alternates − "tab" for tables − "mma" for multimedia and alternates − "sup" for supplies − "seq" for support equipment − "spa" for spares − "par" for levelled paragraphs and alternates − "stp" for steps of procedure, fault isolation, etc, and alternates − "gra" for graphics (multiple sheets) − "mmo" for multimedia objects − "hot" for hotspots (eg, "fig-0001-hot-0002") − "pme" for parameters − "zon" for zones − "wla" for work locations − "mat" for single material or material sets − "acp" for access points
Note: The four digit number has no connection to, eg, the figure or table number which is generated for data module presentation. For example, the value of the attribute id can be "fig-0345" for Fig 1. Refer to Para 2.1. The following prefixes listed shall be used for attributes id and internalRefId.
"fig" for figures and alternates "tab" or "tbl" for tables "mma" for multimedia and alternates "sup" for supplies "seq" for support equipment "spa" for spares "par" for levelled paragraphs and alternates "stp" for steps of procedure, fault isolation, etc., and alternates "gra" for graphics (multiple sheets) "mmo" for multimedia objects "hot" for hotspots (e.g., "fig-0001-hot-0002") BRDP-S1-00102 Use and format of the attribute referredFragment of the element <dmRef>:
| Decide whether to use the attribute referredFragment and, if used, list the precautions. | The use of the attribute referredFragment shall only be used on a limited basis to support program requirements. The program shall have final approval on all instances of its use. It shall not be used to bypass important safety or procedural information. | |
| BRDP-S1-00103 | Use of issue information and language in data module references: |
| Decide whether to use issue and in-work numbers, as well as language and country codes of the destination data module in data module references. In making this decision, the project or organization must be aware of the implications of using the items when referenced data modules are updated. | The use of issue and in-work numbers, as well as language and country codes of the destination data module in data module references is prohibited. | |
| BRDP-S1-00104 | Use of title and issue date in data module references: |
| Decide whether to use the title and the issue date of the destination data module in data module references. | The element <dmTitle> and the element <issueDate> in the element <dmRefAddressItems> shall not be used. | |
| BRDP-S1-00105 | Use of issue information and language in publication module references: |
| Decide whether to use issue and in-work numbers, as well as language and country codes of the destination publication module in publication module references. In making this decision, the project or organization must be aware of the implications of using the items when referenced publication modules are updated. | Issue and in-work numbers as well as language and country codes shall not be used when referencing publication modules. | |
| BRDP-S1-00106 | Population of the element <refs>: |
| Decide if and how the element <refs> is populated. If populated, the order of items in the list must be specified. | The element <refs> shall be populated whenever data modules, publication modules, or other documents are referenced. Entries in <refs> shall not include issue number. References to data modules and technical publications are presented in lexical order, with data modules first. The element <behavior> shall not be used in any <refs> child elements. | |
| BRDP-S1-00107 | Define the words before and after the reference elements: |
Define the words before and after the elements <dmRef>, <pmRef> and <externalPubRef>. This is important as it has implications on the stylesheets used. Example: For one implementation, the stylesheet can automatically generate the words "Refer to data module:" when it recognizes the element <dmRef>. This will cause problems if the author has written "Refer to" within the paragraph before the element <dmRef>. Cross-references shall use the following type wording "(See Figure 1.)". The verb in the cross-reference statement (e.g., "See", "Repeat", "Skip") shall be manually authored. If appropriate, the label (e.g., "Figure", "Para", "Step") shall be generated from the target element (e.g. <levelledPara> = "Para") to avoid any risk of misidentification. The number shall be autogenerated during the publication process. The generated labels are further defined in MIL-STD-3048.
| S1000D Chapter 3.9.5.2.1.3 - Common constructs - Lists | |
| BRDP-S1-00108 | Use of titles for lists: |
| Decide whether to use titles for each of the sequential, random and definition lists. | Titles for lists may be used as determined by the contractor with final approval residing with the program. | |
| BRDP-S1-00109 | Use of the attribute listItemPrefix: |
| Decide whether to use the attribute listItemPrefix, which values to use and allocate suitable definitions to the values. Refer to Chap 3.9.6.1. | Only the values "pf01" (for simple lists, no prefix, only indent) and "pf02" (for unordered lists, which alternates between short dashes and bullets depending on list level) shall be used for the attribute listItemPrefix. | |
| BRDP-S1-00110 | Use of definition list headers: |
| Decide whether to use definition list headers. | The use of definition list headers is prohibited, this function will be handled by the stylesheet. | |
| S1000D Chapter 3.9.5.2.1.4 - Common constructs - Caption groups | |
| BRDP-S1-00111 | Use of applicability information on various caption group child elements: |
Decide whether and how to use the attribute applicRefId of various <captionGroup> child elements. Applicability information shall be used as needed to support program requirements.
The program shall work with the contractor to ensure the program's overall vision of applicability use is understood and implemented properly.
BRDP-S1-00112 Use of color for Tables of contents - attribute tableOfContentType in the element <captionGroup>:
| Decide whether to use the attribute tableOfContentType, (eg, for Table of contents in Flight reference cards). | The use of the attribute tableOfContentsType is prohibited. | |
| BRDP-S1-00113 | Use of the attributes rowsep and colsep in the element <captionEntry>: |
| Decide whether the attriubtes rowsep and colsep rules between <captionEntry> elements are required. | The contractor may use the attributes rowsep and colsep rules between <captionEntry> elements as required to reflect the panel block as accurately as possible. | |
| BRDP-S1-00114 | Use of the local use of spans within the element <captionEntry>: |
| Decide whether the element <captionEntry> spans are to be defined locally or by the element <spanspec>. | The contractor shall decide whether the element <captionEntry> spans are to be defined locally or by the element <spanspec>. | |
| BRDP-S1-00115 | Use of the attribute color in the element <caption>: |
| Decide whether to use the attribute color, which values to use and allocate suitable definitions to the values. Refer to Chap 3.9.6.1. | The contractor may use the attribute color as required to reflect the panel block as accurately as possible. | |
| BRDP-S1-00116 | Use of attribute systemIdentCode in captions: |
| Decide whether and how to use the attribute systemIdentCode. | Use of the attribute systemIdentCode is prohibited. | |
| BRDP-S1-00117 | Inline use of captions: |
| Decide whether inline captions affect the text line spacing and how this is defined. | Text line spacing shall be adjusted to prevent text overlap when inline captions are used. | |
| S1000D Chapter 3.9.5.2.1.5 - Common constructs - Titles | |
| BRDP-S1-00118 | Use of the element <title>: |
| Decide whether and how to use the element <title>. | The elements <figure>, <multimedia>, and <levelledPara> (up to level 5) shall include a <title>. All other elements which allow a title shall be decided by the contractor with final approval residing with the program. When deciding on <title> use, the technical content requirements of the chosen information sets must be followed. | |
| BRDP-S1-00119 | Use of cross-references from titles: |
| Decide whether to allow cross-referencing from titles. | Titles shall not contain references. | |
| BRDP-S1-00120 | Use of titles for the elements <levelledPara> and <proceduralStep> from sublevel six thru eight for legacy data: |
| Decide whether titles can be included for the elements <levelledPara> and <proceduralStep> from sublevel six thru eight when converting legacy data to S1000D. | Not Applicable | |
| S1000D Chapter 3.9.5.2.1.6 - Common constructs - Tables | |
| BRDP-S1-00121 | Use of standard table types: |
| Decide if a list of standard table types applies to the project (eg, inspection, examination) and define what the business rules are for these types in terms of their presentation requirements and certain textual values (eg, titles and heading row values). Each of these standard types must have a defined value that can be applied to the table's attribute tabstyle. | The contractor may create a list of standard table types to apply using the attribute tabstyle if desired. When creating the list of table types, the technical content requirements of the information sets must be considered. | |
| BRDP-S1-00122 | Use of tables as graphics: |
| Decide if tables represented as graphics are allowed, and if they are, in what situations they can be used. | Tables shall not be presented as graphics. | |
| BRDP-S1-00123 | Use of applicability information of various table child elements - attribute applicRefId of the element <table>: |
Decide whether and how to use the attribute applicRefId of various <table> child elements. The child elements can be differentiated based on Product configuration. Applicability information shall be used as needed to support program requirements.
The program shall work with the contractor to ensure the program's overall vision of applicability use is understood and implemented properly.
| S1000D Chapter 3.9.5.2.1.7 - Common constructs - Figures, multimedia and foldouts | |
| BRDP-S1-00124 | Use of applicability information for complete figures and illustration sheets - attribute applicRefId of the element <figure>: |
Decide whether and how to use the attribute applicRefId of various <figure> child elements. The child elements can be differentiated based on Product configuration. Applicability information shall be used as needed to support program requirements.
The program shall work with the contractor to ensure the program's overall vision of applicability use is understood and implemented properly.
BRDP-S1-00125 Use of hotspots:
| Decide whether to use hotspots. | Hotspots on graphics shall be used. | 0 |
| BRDP-S1-00126 | Use of legends: |
| Decide whether to use legends. | Legends shall be used as needed to support the technical content requirements listed in the chosen information sets. | |
| BRDP-S1-00127 | Use of leading zeroes in the element <listItemTerm>: |
| Decide whether the element <listItemTerm> is to contain a leading zero when using callout/item numbers. The default is no leading zero. | When using the element <listItemTerm>, callout/item numbers shall not include leading zeros. | |
| BRDP-S1-00128 | Types of legends: |
Decide on the strategy for legends. Legends can appear as part of the illustration or as text using the element <legend>. The advantage of making the legend part of the text is that:
- the same illustration can have different legends wherever it appears (eg, in multilanguage projects)
- the text of the element <legend> can be searched (this might not be the case if the legend is part of the illustration)
- items in the illustration can be linked to the legend by the use of hotspots
| - the legend in the text can save space on the illustration (particularly when the legends are long) | Legends shall appear as text, authored using legend markup. | |
| BRDP-S1-00129 | Suitability of multimedia use: |
| Decide whether using multimedia is suitable for the environment in which the project will operate. | Mutlimedia requirements (if any) are listed in the functionality requirements worksheet and the TMCR. | N/A |
| BRDP-S1-00130 | Permitted types of multimedia: |
This is the start of the file's text. The full file is on GovTribe.
