MIL-M-28001A APPENDIX A TEMPLATE DOCTYPE FOR TECHNICAL DOCUMENTS MARKUP TAGS 10. SCOPE 10.1 Scope. This appendix specifies the role played by the Document Type Declaration in an SGML implementation; a general description of document type declaration structure and content; the Template Document Type Declaration Set and Baseline Tag Set available for use in authoring and technical publication verification of an SGML-tagged technical document; and procedures for document type declaration development. This appendix is a mandatory part of the specification. The information contained herein is intended for compliance. 20. APPLICABLE DOCUMENTS 20.1 Applicable documents. This section is not applicable to this appendix. -24- MIL-M-28001A APPENDIX A 30. INTRODUCTION 30.1 Purpose. This introduction establishes the basic concepts of SGML. Included in this introduction are an overview of the concepts behind the ISO 8879 (SGML) Standard, a brief tutorial on reading an SGML Document Type Declaration, guidelines for using the SGML tags, and DoD's SGML Declaration. 30.2 ISO 8879 - background. The Standard Generalized Markup Language (SGML) was published as International Standard 8879 in October 1986. It is a metalanguage for describing the logical and content structures of a document in a machine processable syntax. The early work on the standard was done inside ANSI X3J6, Programming Languages. Eventually, the charter for the group was modified and they were moved to X3V1 whose name was changed to Text Processing: Office and Publishing Systems. It was via this body that SGML moved through the final steps necessary to become an ISO standard. This international exposure has given SGML the advantage of close scrutiny by international experts in the field of publishing. 30.3 IS0 8879 - general concepts. Because SGML is a metalanguage that does not target any one application, it can be used as a tool for all types of applications. SGML is not written with a bias toward technical, financial, office, insurance, or legal publishing. It is used to describe textual data; that data can be a novel or a mathematical equation. The use of a document type declaration defines a specialized markup language for use with a specific application. This is one of the most powerful concepts behind SGML. Through an SGML document type declaration an application can rigorously and strictly define the structure of a class of documents such as job guides, flight manuals, fault isolation procedures, etc. These definitions can be created in the linguistic terms of the application. It is not necessary to refer to all blocks of text as a paragraph when it might be more appropriate to refer to one block of text as the `scope' of the document, another block of text as a `third-level procedural step,' another block of text as a `preflight checklist challenge,' etc. This ability to tailor descriptive tags to the application helps shorten training times as well as facilitate data access. As a language for text description, SGML is not procedural nor is it concerned with the output device or even the absence of one. The document can be subsequently processed for braille delivery, on-line screen delivery, audio delivery, machine-to-machine delivery, paper delivery, data base loading, or all of these purposes. Because it is not better suited for one type of delivery method over another, it is not less suited for any one type of delivery method. It has no biases toward or against the description of tabular material, mathematic formulae, or other complicated textual constructs. Perhaps its most attractive feature is that text coded in SGML can be used in many different ways without conversion or manual intervention with the data. A variety of output requirements can be overlayed on the -25- MIL-M-28001A APPENDIX A logically structured document to serve the most diverse needs. This specification focuses primarily on the paper publication of a document. 30.4 Reading a document type declaration. This section provides a brief, informal tutorial on how to read and interpret a document type declaration. It is not meant to be a substitute for the standard, which should be consulted for the formal rules of SGML. 30.4.1 Unfielded data. Text processing is unlike other data processing applications in that the data is unfielded. In data processing, it is a fairly straightforward procedure to identify where the zip code can be found in a data stream. In text processing, it is more complex because there is no data base definition available for reference. To remedy that situation, it is necessary to devise a way to describe the unfielded data base containing the textual information. Where a particular element starts and ends is based upon where it occurs in relationship to other elements and on identifiers marking its starting and ending positions. To describe an element's permissible positions and relationships to other elements in the document, SGML uses a document type declaration. 30.4.2 Document type declaration example. A document type declaration is a concise statement of what element types, entities, attributes, etc. are allowed in a particular document (see `Definition of Terms'). These items are made available for use through declarations. For example, the following shows two ways in which to describe what content and structure a memo may have. Natural language description: Memoranda prepared by this office shall conform to the following guidelines. It is important that all memos be dated. There may be more than one recipient of the memo, as well as more than one sender (author). Always list all recipients first then all authors. It is our policy to list all courtesy and blind copies at the start of the memo, rather than at the end. Always list the name, position, and mail stop for each recipient, author, courtesy copy, and blind copy. A reply date may also be specified. Each date should be listed in day, month, and year order. Each memo should have a stated subject. Additionally, an abstract can also be given that summarizes the information in the body of the memo. The body of the memo can contain paragraphs. If needed a paragraph's content may be subdivided. -26- MIL-M-28001A APPENDIX A *************************************************** SGML description: ] > Comparison of descriptions: Both of these descriptions of the memo are useful. The first way uses natural language to describe to a human being the components of a memo, and when they are to be used. The second method is an SGML document type declaration. It uses the SGML metalanguage to describe the components of a memo. This second method uses a rigorous syntax for this description in addition to terms within the application knowledge of the user. It is, therefore, human-readable and machine- processable. This example clearly points out that SGML is like a mirror that can be held up to different applications. In the case of MIL-M-38784, 46 pages are devoted to a description of both the logical structure and the format of conforming documents. SGML is a vehicle for succinctly, accurately, and rigorously describing the logical structure of a document. It can also be used to describe the format of a document, although that would take place in a separate document type definition. -27- MIL-M-28001A APPENDIX A 30.4.3 Declarations within the document type declaration. The different types of declarations in the document type declaration all begin with a markup declaration open of `'. A declaration that will be used throughout this discussion is the comment declaration, shown as: . The double hyphen serves as both the start and end comment delimiters. 30.4.3.1 Document type declaration. The first declaration is the document type declaration itself: The document type declaration subset contains the other types of declarations. 30.4.3.2 Notation declaration. A notation declaration identifies a data content notation used within the document. This is used in the accompanying application to identify data content notations for IGES, CGM, CCITT Group 4, and others. A notation declaration follows the form: 30.4.3.3 Entity declaration. An entity declaration follows the form: The entity text is the information needed to identify the entity. It may be a quoted version of the entity's replacement text or a quoted string identifying an external entity. The entity's replacement text is the real `text' of the entity: that text that replaces a reference to the entity when the reference is detected during parsing. The entity's replacement text may be additional SGML text or non-SGML data. If it is SGML text, it may be located physically in the declaration or the declaration may refer to a location on the system or to some publicly known text. If it is non-SGML data, the appropriate data content notation must be specified. Entities can be of two varieties: general and parameter. General entities are declared in the document type declaration and are referenced in the document instance by the author or editor of a document to refer to an internally or externally defined portion of content. An example of a general entity is: -28- MIL-M-28001A APPENDIX A It would be referenced with: &dod; Parameter entities are declared in the document type declaration also. However, they are typically referenced in the document type declaration as itself, rather than in the document instance. Parameter entities are often used as a shorthand method for specifying long model groups or other constructs that may be used many times. An example of this is the declaration: It is referenced with: %text; Note: General entity names can be 32 characters long (in the applications in this specification) and use an ampersand as an entity reference opening delimiter and a semicolon as the reference closing delimiter. Parameter entity names can be 31 characters long (in the applications in this specification). The declaration contains the use of a percent sign and whitespace before the parameter entity name, and the entity is referenced with a percent sign as the parameter entity reference opening delimiter and a semicolon as the reference closing delimiter. (The percent sign is included in the 32 character count.) Caution: A space or a record end following an entity reference will be interpreted as a reference closing delimiter. Therefore, textual constructions such as `R&D ' and `AT&T ' should be avoided as the `&D' and the `&T' will be interpreted as entities. In such circumstances, an entity reference can be used in place of the ampersand (`&' from the Numeric and Special Graphic character set). Parameter entities are also used as a way to parameterize a particular portion of the document type declaration for future manipulation. For example, in MIL-M-38784, there are guidelines for the order in which front matter elements may occur. In another specification that order may be different. If the content model of front matter is given as a parameter entity reference, the entity can be redefined to suit the appropriate specification. See 30.5.1 for additional information on the use of this convention in this application. 30.4.3.4 Element type declaration. To describe how and when elements may occur, SGML makes use of element type declarations. They contain the name of the element type (or a parenthesized group of element type names), the start- and end- tag minimization that may be -29- MIL-M-28001A APPENDIX A used (if any), and the declared content or content model of the element type. If an element type has `declared content,' it will be specified as either `CDATA' (character data in which no markup is recognized other than the delimiters that end the character data), `RCDATA' (character data in which no markup is recognized other than general entity references, character references, and the delimiters that end the character data), or `EMPTY' (no content is permitted). In each of these, the element is a terminal node of the document's hierarchy and can contain no other subelements. If an element type has a `content model,' its content can be either a `model group' (specified allowable subelement structure) or `ANY' (any elements defined in the same document type declaration are allowed). Parsed character data (#PCDATA) may also appear in a content model. (It must be specified in the model group, if there is one.) Additionally, exceptions may be part of the content model. 30.4.3.5 Model group. A `model group' is a list of element type names, the identified keyword `#PCDATA', and/or smaller model groups, enclosed in group delimiters, parentheses. 30.4.3.5.1 Use of connectors. Elements listed within a group are separated by `connectors.' There are three types of connectors: a. the `seq' (sequence) connector is the comma (,) -it indicates that the elements within the group occur in the order or sequence in which they are encountered; b. the `or' connector is the vertical bar ( | ) -it indicates that only one element within the group may be used each time the group is evaluated; and c. the `and' connector is the ampersand (&) -it indicates that the members of the group may occur in any order. The `and' connector adds contextual ambiguity and generally should be avoided in new document type declaration development. Only one type of connector may join elements at the same level within a group. Of course, within a subsidiary parenthesized group a different connector could be used. Some examples follow: -30- MIL-M-28001A APPENDIX A 30.4.3.5.2 Use of occurrence indicators. In addition to connectors, SGML also provides occurrence indicators. Occurrence indicators may modify a group or individual element type. They are: a. the `opt' (optional) occurrence indicator, the question mark (?), indicates that the element type or group may occur zero or one time; b. the `plus' occurrence indicator, the plus sign (+), indicates that the element type or group must occur once, but may be repeated; c. the `rep' (repetition) occurrence indicator, the asterisk (*), indicates that the element type or group may occur zero or more times; and d. no occurrence indicator means that the element type or group must occur once and only once. -31- MIL-M-28001A APPENDIX A Some examples follow: 30.4.3.6 Use of inclusion and exclusion exceptions. Inclusion exceptions permit logically independent element types to occur zero or more times within an instance of a model group before, between, or after any of the element types in the model group, or any expansion of subsidiary model groups therein. An exclusion exception prevents -32- MIL-M-28001A APPENDIX A occurrences of excluded element types from an instance of a model group, even if the same named element type were in an inclusion. The notation for inclusion exceptions is +(element_type_group). The notation for exclusion exceptions is -(element_type_group). The element_type_group connector may be any sequence connector (`or' is used in the example). For example, has the effect of preventing recursive footnotes, nested within each other. This seems an appropriate use, since placement and numbering of nested footnotes is cumbersome. 30.4.3.7 Start- and end-tag minimization. Start- and end-tag minimization is a feature of the language. In this application, the OMITTAG feature has been chosen. It allows the systematic elimination of the end-tags of various elements within a document. In the element type declaration, the end-tag omission parameters follow the element type name and precede the content of the element type. A hyphen (`-') specifies no omission; the letter `o' specifies that the tag need not be used if omissible under the rules of minimization outlined in the standard. Once a parser has determined whether or not minimization of a tag is allowable based on the standard, it must also check the element type declaration of the element in question, to determine if the application designers have specified that the tag may be eliminated. For example, consider the following element type declarations: In this example, the document contains front, body, and rear matter. The two hyphens between the word `doc' and the content model signify that the start- and end-tags for `doc' must be used. The front matter is the first and only thing that can occur immediately following the `doc' element start-tag. In this case, `front' is contextually required, therefore the start-tag may be eliminated. However, the element type declaration for front also specifies a hyphen in the start-tag-minimization field as well as the end-tag-minimization position. Therefore, even though the rules of minimization would have allowed the user to leave off the start-tag, the application designers have decided that its absence should be reported as an error. -33- MIL-M-28001A APPENDIX A A second example demonstrates the reverse of this in effect: The start-tag for the safety summary may not be minimized, but the end-tag may be omitted. Once the safety summary is started, an optional paragraph may appear or a list may start. Since the paragraph is not contextually required in this instance, its start-tag must be used if the paragraph element type occurs. Whether or not a paragraph is used, a list must occur. After the list is over, one paragraph must be used. In this example, one paragraph is contextually optional and one is contextually required. By looking at the element declaration for a paragraph, we see that the application designer has specified that the start- and end-tags for the paragraph are not required where they may be omitted under the rules for tag omission. In other words, if under the rules for tag omission, the start-tag of an element may not be omitted, an error must be reported if the start-tag is not encountered. On the other hand, if the rules for tag minimization allow the omission of the tag, its omission will not be reported as an error, unless the start-tag-omission parameter of the relevant element declaration forbids the omission of the tag. 30.4.3.8 Attribute list declaration. The last type of declaration is the attribute list declaration. Attributes are additional data to be provided about element types. Each list of attribute definitions is associated with one or more elements types. However, an element type may have associated with it at most one attribute definition list. For example, in the MIL-M- 38784B application of this specification, security classification is one of the attributes of many types of elements. A simplified version follows: -34- MIL-M-28001A APPENDIX A A specific set of keywords can be used in attribute declared values. These include: CDATA (any usable characters as defined by the SGML declaration), NAME (conforms in length to the NAMELEN parameter from the SGML Declaration, begins with a name start character -- alpha by default, and has name characters -- alpha, numeric, `-', `.', by default -- for the rest of the characters), NAMES (one or more NAME separated by one or more parameter separator characters -- space, tab, record end, etc), NMTOKEN, (begins with and contains name characters), NMTOKENS (one or more NMTOKEN), NUMBER (all digits, conforms to NAMELEN), NUMBERS (one or more NUMBER), NUTOKEN (begins with a digit and then contains name characters), NUTOKENS (one or more NUTOKEN), ENTITY (syntactically conforms to NAME and refers to a declared, externally defined, NDATA (and SUBDOC) entity, ENTITIES (one or more ENTITY), ID (a unique identifier conforming syntactically to NAME), IDREF (references an ID), or IDREFS (one or more IDREF). ISO 8879, clause 11.3.3 should be consulted for a complete list. 30.4.3.9 External entities. External entities are commonly used entities kept separate from any one document type declaration, and their entity declaration within any one document's document type declaration simply contains a special identifier, either publicly known or known only to a particular system, which identifies it. A common use of external parameter entities is to contain an oft-used set of declarations that might be incorporated by reference within the document type declaration of a document. The replacement text of such an entity is a document type declaration set (see 6.7), and if the document type declaration set is appropriate to make up most or all of the declarations within a document type declaration, it is sometimes incorrectly called a `DTD.' Note that a document type declaration set does not contain a DTD -- only -35- MIL-M-28001A APPENDIX A declarations that can go into the document type declaration subset of a document type declaration. Similarly, if the replacement text of such an entity is entirely comment and entity declarations, it is known as an `entity set.' The terms `document type declaration set' and `entity set' apply to the replacement text of these entities. They are also used to describe the external entities themselves, provided the resolution of any parameter entities contained within the external entity is consistent with the containing entity's role as either a document type declaration set or entity set. 30.5 Guidelines for document type declaration creation. 30.5.1 Choosing the appropriate document type declaration set. Appendix A and Appendix D contain two document type declaration sets. The second document type declaration set (Appendix D, Section 30) shall be used when preparing documents that conform to MIL-M-38784B. It shall also be used when preparing documents that conform to any of the other specifications cited in 1.2, by including a reference to it along with additional declarations required by the other specifications. In many cases, only the addition of a few entity declarations for specifying constant text or standard tables are required. In other cases, minor changes to the content models of specific element types in the MIL-M-38784B document type declaration set are needed to describe the structure of another specification. In order to accommodate this need for alternate definitions of content models, a convention was adopted to `parameterize' the content model of element types. Parameter entities are referenced as the content of various elements in the public document type declaration set for MIL- M-38784B. The replacement text of each of these parameter entities is the appropriate content model for the element type in which it is referenced. If an alternate content model is required for one of these element types in one of the other cited specifications (see 1.2), an alternate declaration is supplied in the public declaration set associated with that specification. Note: If an entity is declared more than once, all subsequent definitions are ignored. If an element type is declared more than once, it produces an error. For this reason, the content models of certain element types are parameterized, making it unnecessary to redefine the element type itself. It is only necessary to assure that the appropriate entity declaration is read first. An SGML parser reads the document type declaration subset first and then reads the externally-defined document type declaration set. The first entity declaration found, whether in the document type declaration subset or in the public document type declaration set, will be used and all others ignored. -36- MIL-M-28001A APPENDIX A Appendix D, Section 30 accommodates a family of specifications, all closely related to MIL-M-38784. The public identifier for MIL-M-38784B refers to a declaration set. A user of this document type declaration set cites the public identifier and then lists any other declarations that pertain specifically to their instance of the document type declaration. These would typically include notation declarations and entity declarations for graphics, text (such as notices), and character sets. Example: %distrb; ]> The additional document type declarations are also defined as groups of declarations that can be referred to with a public identifier. Within these groups of declarations, there is also a declaration that refers back to the MIL-M-38784B public declaration set. In this way, the new public identifiers refer to a combination of the original public declaration set for MIL-M-38784B documents as well as the additional declarations that refer to the associated document type. The following is an example: -37- MIL-M-28001A APPENDIX A %M38784B; An example of the use of the public document type declaration might be: ]> In this example, the public identifier in the document type declaration refers to the collection of declarations that includes a parameter entity declaration (frnt) for the content model of the `front' element, a parameter entity declaration (M38784) for the original public declaration set for MIL-M-38784B documents, and a parameter entity reference (%M38784B;) to that public declaration set (which in effect resolves, or includes, all of the declarations in the public declaration set for MIL-M-38784B). The user then lists the entities particular to their document instance. A declaration set has been prepared for each of the cited specifications (see 1.2) other than MIL-M-38784. In many cases, the additional declarations are entities defining constant text (see 30.5.2) or parameter entities that are used to redefine a parameter entity declared in the MIL-M-38784 declaration set. These additional declarations can be found in Appendix D, beginning with Section 30.1. The first document type declaration set (Appendix A, Section 50) uses the same element types that occur in the second document type declaration with the addition of more subordinate paragraphs and steps, and a few other element types. While constraining use to certain groups of element types in certain contexts, it does not limit occurrence or sequence within those groups. The document type declaration set in Appendix A Section 50 provides, where appropriate, a model that can be used directly, or which can be used as a template for development of a document type declaration appropriate to a document whose structure conforms to other specifications (see 1.2). 30.5.2 Inclusion of standard text. In order to use standard text within a document, general entities have been created. It is through the use of these entities that the appropriate standard text is specified for use. -38- MIL-M-28001A APPENDIX A 30.5.3 Standard text conventions. There are many instances of constant text that must be used in a technical manual. This text is generally provided by the governing specification. General entity declarations have been created to accommodate the use of this type of text. These entity declarations have been logically grouped within Appendix C as the value of publicly identified entities. For example, a public entity has been created for distribution notices. The following text is an excerpt from Appendix C: The declarations for the two entities &distrib; and &distrib1; are the replacement text of the public entity &distrb;. The replacement text of &distrib; is the text of the distribution notice. Within &distrib; there is also a call to a second general entity with the name &distrib1;. This entity specifies the applicable activity cited in the distribution notice. As that information will change from document to document, it is necessary for the originator to create an entity declaration for &distrib1; in the declaration subset of the document type declaration prior to referencing the public entity set &distrb; for each document in which a reference to &distrib; occurs. When the originator creates the document, the first thing needed after the SGML declaration (discussed later) is the document type declaration. The originator would use one similar to the following, based on the individual needs of the document. -39- MIL-M-28001A APPENDIX A %distrb; ] > This document type declaration cites the public document type declaration set as defined in Appendix D, Section 50 and the public entity set defined in Appendix C. It has a document type declaration subset that defines the entity &distrib1;. This definition will supersede the definition for this entity in the public entity set. If the standard text for &distrib; were inappropriate for the document being created, the originator could create an entity declaration for &distrib; with the new text, which would override that in the public entity set. The originator could also use text directly in the content of the appropriate and not use &distrib;. 30.5.4 Using special characters. Appendix C contains a list of character sets approved for use in documents prepared using this specification. They are grouped by category for ease in locating and using the appropriate special character. Each document type declaration defined in the appendices of this specification contains parameter entity declarations that refer to five character sets as defined in ISO 8879, Information Processing -- Text and Office Systems -- Standard Generalized Markup Language. (SGML). Selected entity sets from Appendix C are referenced directly within the document type declaration sets of this specification; the other entity sets may be referenced individually as required. If a particular character set is needed in a document, and that character set is not one of the five included in the public document type declaration sets, the entity defining that set should be included in the document type declaration subset for that document. The following is an example of this use: %ISOgrk1; ]> In this example, the public identifier in the document type declaration refers to the collection of declarations for MIL-M-38784B conforming document. The declaration subset includes a parameter entity declaration (ISOgrk1) for the public entity set for Greek letters and a parameter entity reference (%ISOgrk1;) to that public entity set (which in effect resolves, or includes, all of the declarations in the public entity set for ISOgrk1). To use a particular character in the document, the originator designates its use with an entity reference. For example, if the small Greek symbol, pi, is needed, it is referenced as follows: text text text text text text π text text text text text NOTE: Entity references are not recognized in CDATA. 30.5.5 Using graphics and other non-SGML data. Graphics and other non-SGML data may be identified for use within an SGML document through the use of notation and external entity declarations. Notation declarations define a type of data content and optionally supply a system identifier which gives information about processing such content. External entity declarations define the entity to be included and the type of data content it contains, and optionally specify in some manner how the system is to find the text of the entity. Typically, these entities refer to graphics within the document. Appendix C contains a list of all approved notation declarations. A notation declaration must be used for each type of non-SGML data used in any of the document's entities. Any appropriate notation declarations and all non-SGML entity declarations are placed in the document type declaration subset. The following is as an example of how non-SGML data content notations and graphics to be used within the document should be declared in the document type declaration subset. ] > -41- MIL-M-28001A APPENDIX A Optionally, a literal string may be added to the declaration (see MIL-STD-1840): ] > Alternatively, some graphics may be publicly identified and would be declared using their public external identifier: ] > 30.5.6 Coordinating the Use of the Appendixes. Table I in Appendix A, Section 70 contains an alphabetical listing of all element types contained in the document type declaration set in Appendix A. The listing for each element type gives a brief description of the purpose of the element type and lists any required or optional attributes with explanations of the declared and default values. The document type declaration used for the specific document should be consulted for the elements that can be used, in what order, how often, and with what minimization. The basic tag set descriptions should be consulted for specifics on the meaning of attributes. 30.5.7 SGML declaration. The following is the SGML Declaration to be used in conjunction with document type declarations. It declares the character set, syntax, quantities, capacities, scope, and features of SGML to be used. -42- MIL-M-28001A APPENDIX A -43- MIL-M-28001A APPENDIX A 40. SGML DOCUMENT TYPE DECLARATIONS 40.1 SGML document type declarations. A document type declaration provides application specific rules for technical publication verification that a marked-up document has conformed to the rules established for the application. 40.2 Document type declarations for documents other than those cited in 1.2. When contract require- ments for technical preparation do not specify use of the document type declarations for the specifications cited in 1.2, then an alternate document type declaration may be used. The document type declaration in Appendix A, Section 50, may be used or it may be used as a template for document type declaration development. 40.3 Document type declaration for MIL-M- 38784B conforming documents. The primary document type declaration set in Appendix D, Section 30, defines the complete logical structure established for technical manuals by MIL-M-38784B. For documents conforming to other selected specifications as shown below, the declaration sets in the associated subsections of Appendix D, Section 30, may be used; they modify the primary document type declaration set appropriately for the technical manual structure as prescribed by the specifications below. ______________________________________________________________________ |Document Type| Section # | Associated Public Identifier | | |in Appendix D| | |_____________|_____________|_________________________________________| | | | | |MIL-M-21742A | 30.1 |"-//USA-DOD//DTD MIL-M-21742 900102//EN" | | | | | |MIL-M-26788C | 30.2 | "-//USA-DOD//DTD MIL-M-26788 900102//EN" | | | | | |MIL-M-38812 | 30.3 | "-//USA-DOD//DTD MIL-M-38812 900102//EN" | | | | | |MIL-M-63004B | 30.4 | "-//USA-DOD//DTD MIL-M-63004 900102//EN" | | | | | |MIL-M-63036A | 30.5 | "-//USA-DOD//DTD MIL-M-63036 900102//EN" | | | | | |MIL-M-63038B | 30.6 | "-//USA-DOD//DTD MIL-M-63038 900102//EN" | | | | | |MIL-M-63041C | 30.7 | "-//USA-DOD//DTD MIL-M-63041 900102//EN" | | | | | |MIL-M-6675B | 30.8 | "-//USA-DOD//DTD MIL-M-6675 900102//EN" | | | | | |MIL-M-83493 | 30.9 | "-//USA-DOD//DTD MIL-M-83493 900102//EN" | | | | | |MIL-M-9994B | 30.10 | "-//USA-DOD//DTD MIL-M-9994 900102//EN" | | | | | |WS-10759, | 30.11 | "-//USA-DOD//DTD MIL-M-10759 900102//EN" | | -1, -2,-3 | | | |_____________|_____________|__________________________________________| -44-