MIL-M-28001B 26 June 1993 SUPERSEDING MIL-M-28001A 20 July 1990 This specification is approved for use by all Departments and Agencies of the Department of Defense. MILITARY SPECIFICATION MARKUP REQUIREMENTS AND GENERIC STYLE SPECIFICATION FOR ELECTRONIC PRINTED OUTPUT AND EXCHANGE OF TEXT 1. SCOPE 1.1 Scope. This military specification establishes the requirements for the digital data form of page-oriented technical publications. Data prepared in conformance to these requirements will facilitate the automated storage, retrieval, interchange, and processing of technical documents from heterogeneous data sources. The requirements set forth by this military specification include: a. procedures and symbology for markup of unformatted text in accordance with this specific application of the Standard Generalized Markup Language (SGML), b. SGML compatible codes that will support encoding of a technical publication to specific format requirements applicable to technical manuals, c. output processing requirements that will format a conforming SGML source file to the style and format requirements of the appropriate Formatting Output Specification Instance (FOSI) based on the Output Specification (OS). AMSC N/A AREA IPSC DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited. 1.2 Specifications covered. This specification establishes the requirements for the digital encoding of all technical publications. Data files satisfying the requirements of this specification will be one of the following types: Type I. Technical manuals conforming to MIL-M-38784 or related specifications having public document type declaration sets. Type II. Technical manuals, or other documents conforming to other military specifications or requirements. 1.3 Disposition of Document Type Declarations. Document type declaration sets are declaration sets intended for inclusion within a document type declaration. They consist of one or more entity sets and/or element type sets. They are appended to their respective functional specifications. 2. APPLICABLE DOCUMENTS 2.1 Government documents. 2.1.1 Government specifications, standards and handbooks. The following specifications, standards and handbooks form a part of this document to the extent specified herein. Unless otherwise specified, the issues of these documents are those listed in the Department of Defense Index of Specifications and Standards (DODISS) and supplement thereto in the solicitation (see 6.2). SPECIFICATIONS MILITARY MIL-M-38784 - Technical Manuals: General Style and Format Requirements STANDARDS MILITARY MIL-STD-1840 - Automated Interchange of Technical Information (Unless otherwise indicated, copies of federal and military specifications, standards, handbooks are available from Standardization Documents Order Desk, Building 4D, 700 Robbins Avenue, Philadelphia, PA 19111-5094.) 2.2 Non-Government publications. The following document(s) form a part of this document to the extent specified herein. Unless otherwise specified, the issues of the documents which are DoD adopted are those listed in the issue of the DODISS cited in the solicitation. Unless otherwise specified, the issues of documents not listed in the DODISS are the issues of the documents cited in the solicitation (see 6.2). INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO) ISO 8879 - Information processing - Text and office systems - Standard Generalized Markup Language (SGML). (Copies are available from the Standardization Document Order Desk, Building 4D, 700 Robbins Ave, Philadelphia, PA 19111-5094, for issue to DoD activities only. All other requestors must obtain documents from the American National Standards Institute, 11 West 42nd Street, 13 Floor, New York, NY 10036.) 3. REQUIREMENTS 3.1 Text markup. Textual material prepared in accordance with this specification, shall be marked up (tagged) in a manner that conforms to ISO 8879 (SGML). SGML shall be used: a. to describe the logical structure of technical publications in unambiguous grammar, b. to assure automated quality control over adherence to that structure, and c. to deliver and store technical publication text in the most easily maintained and updated form. 3.1.1 Source file delivery requirements. Textual material marked up in accordance with this specification is referred to as a source file. A complete SGML-tagged source file(s) is a mandatory part of each final product, and shall be delivered in accordance with MIL-STD-1840. 3.1.2 Support file delivery requirements. Delivery of support files (e.g. FOSIs, SGML encoded text files, and document type declaration sets) shall be in accordance with 3.2 and 3.3 of this specification and in accordance with MIL-STD-1840. 3.1.3 Output file delivery requirements. When specified, an output file (see 6.7.2.17) in accordance with 3.5 shall be provided. 3.1.4 Interim and partial document delivery requirements. Interim or partial delivery of a document allows for Government review prior to final delivery. Partial document delivery allows for portions of a document that has already been delivered to the Government to be updated by sending only the affected parts of the document. Interim deliverables, if required, are specified in the contract and may include a source file, output file, or other specified format. Partial document source file deliveries shall include the file described in 6.5.4.1.2. 3.2 Document structure. The following paragraphs establish requirements for SGML Document Type Declarations. A document type declaration shall be used to define the organization and logical structure of elements, entities, and attributes allowed in a particular document. It shall also be used to control automated processing functions (such as parsing) that support quality assurance requirements. The document type declaration of any publication prepared in accordance with this specification shall reference a publicly identified document type declaration set appropriate for the detail specification it is prepared against, if such exists, and shall not be modified. If no such publicly identified document type declaration set exists, one shall be prepared in accordance with appendix A of this specification. 3.3 OS and FOSI. The OS provides a set of formatting characteristic values used to rigorously describe composition processing functions to be performed on the elements of a text document to provide the format style required by a functional specification. A FOSI delivered with the document shall contain values for characteristics (and attributes if they affect the formatting) for every significant tag used in the document type declaration, and for every context in which the tag has a unique formatting requirement. 3.4 Page integrity (see 6.5.1.4). Requirements for page integrity shall be as specified in the contract (see 6.2). 3.5 Output files. When specified, an output file shall be provided as an interim deliverable (see 3.1.4 and 6.2). When specified, an output file shall also be provided as a final deliverable in addition to the SGML-tagged source file. 3.6 Special features. Special features shall be defined as specified. 3.6.1 Spell checking. When required, the contractor shall check spelling and assure accuracy prior to delivery. 3.6.2 Hyphenation. When required, the contractor shall hyphenate in accordance with acquisition documents (see 6.2 and 6.5.2.2). 4. QUALITY ASSURANCE PROVISIONS 4.1 Responsibility for inspection. Unless otherwise specified in the contract or purchase order, the contractor is responsible for the performance of all inspection requirements (examinations and tests) as specified herein. Except as otherwise specified in the contract or purchase order, the contractor may use his own or any other facilities suitable for the performance of the inspection requirements specified herein, unless disapproved by the Government. The Government reserves the right to perform any of the inspections set forth in the specification to ensure that supplies and services conform to prescribed requirements. 4.2 Responsibility for compliance. Contract deliverables shall meet the requirements of sections 3 and 5. The inspection set forth in this specification shall become a part of the contractor's overall inspection system or quality program. The absence of any inspection requirements in the specification shall not relieve the contractor of the responsibility of ensuring that all products or supplies submitted to the Government for acceptance comply with all requirements of the contract. Sampling in quality conformance does not authorize submission of known defective material, either indicated or actual, nor does it commit the Government to acceptance of defective material. 4.3 Quality assurance requirements. MIL-M-38784 identifies quality assurance requirements for technical publications. A SGML Document Type Declaration and appropriate FOSI shall be used to support the accomplishment of technical publication verification. 5. PACKAGING 5.1 Packaging requirements. The requirements for packaging shall be in accordance with MIL-STD-1840. 6. NOTES (This section contains information of a general or explanatory nature that may be helpful, but is not mandatory.) 6.1 Intended use. Preparation of technical publications in an automated support environment can be viewed as a multi-step process: a. Creating a document type declaration for publication control if one does not exist; b. Creating a FOSI if one does not exist to specify the formatting to be applied to documents conforming with the document type declaration; c. Authoring the publication and inserting SGML markup tags; d. Verifying that the syntax is correct according to the rules of SGML; e. Using a FOSI and document type declaration to direct the composition of the document so that the produced (printed or displayed) copy corresponds to the proper format and style; f. Optionally, reviewing the document electronically using SGML for the comments; and g. Optionally, generating a text presentation metafile in a page description language (PDL) to drive the display device, such as a printer or typesetter. This specification addresses all the steps in the publication preparation process with the exception of the authoring process. Refer to MIL-M-38784 and applicable service Technical Manual (TM) functional specifications for detailed authoring requirements. It is in the interest of both DoD and industry to agree on the most widely applicable set of conventions for the preparation and interchange of technical publications for both defense and non-defense use. The preparing office for this specification encourages proposals that would contribute toward this goal. For example, the Air Transport Association (ATA) is developing an SGML application for use within the commercial airline industry, and both ATA and DoD have expressed interest in collaborating on common specifications. The Society of Automotive Engineers (SAE) has already published a specification (AS4159) that makes use of DoD specifications and standards for automated interchange of technical standards. 6.1.1 Source file delivery. Appendices A, B, and C provide the tools for steps a, b, and c above, the result of which is a complete publication source file, or input file, together with a document type declaration support file when required by 3.2. Delivery requirements for source files are in 3.1.1. It is the source file to which all subsequent changes and updates must be made to maintain the technical publication throughout its operational life. Therefore, the source file is a mandatory final deliverable when this specification is cited in the contract. Source files containing either the complete text of the technical publication, or portions of the text, may be delivered as interim products. Through the use of the SGML declaration (appendix A, 30.7), the document type declaration, the tag descriptions, the output specification and a FOSI, the delivered source will contain the required information for subsequent processing. An appropriate SGML document type declaration set should be developed and used both for document preparation and for technical publication verification that the document conforms to the logical constructs within the document type declaration set. 6.1.2 Support file delivery. An SGML document type declaration set is used in steps a, b, and c above. Appendix B provides an output style and formatting specification used to accomplish step e in the document preparation process. The document type declaration set and FOSI are the support files, delivery requirements for which are in 3.1.2. If a public document type declaration set is used as publicly defined, it need only be cited with the delivery. However, the text of the document type declaration set support file must be delivered with the source file when the technical publication does not conform to the requirements of public document type declaration sets. A complete FOSI must be delivered with the source file until publicly identified FOSIs are available. 6.1.3 Output file delivery. Step g in the document preparation process uses a PDL to produce an output file, sometimes called a text presentation metafile, to drive an output device such as a printer. 6.1.4 Illustration files. This specification provides the tags by which raster or vector illustration files can be referenced in the source file, and incorporated in the final composed technical publication document. Preparation requirements for technical publication illustration files are addressed in MIL-STD-1840. Delivery requirements for technical publication illustration files are in MIL-STD-1840. 6.1.5 Tables. Tables are typically included as SGML-tagged text in the source file. The definition of the table may be explicitly included in the document instance or may be included through the use of an entity reference to an external or internal table definition. If an external entity is used, it may be one that is publicly identified or one that is created for use with a particular document instance and is known as a SYSTEM external entity. A publicly identified entity need not be submitted with a MIL-STD-1840-compliant deliverable, although it must be cited in the document type declaration submitted with the document instance. A SYSTEM external entity declaration must be submitted with the MIL-STD-1840-compliant deliverable. When creating a tagged instance for a specific document or contract, tables can also be delivered as illustration files (using the graphic element type) where preparation requirements make this alternative more cost effective, or where preparation requirements exceed the capability of the markup tags in the reference DTD. Delivery of tables as separate illustration files seriously limits their utility for additional processing, and is discouraged. 6.1.6 Hardcopy and softcopy application. The delivery options in this specification (see 6.1.2, 6.1.3, 6.1.4, and 6.1.5) should be applied based on an analysis of how the information is to be used. For example, an output (PDL) file can be used for both electronic publishing of hardcopy and electronic softcopy display, but it cannot support interactive retrieval as can an SGML-tagged text source file. 6.2 Acquisition requirements. Acquisition documents must specify the following: a. Title, number, and date of the document, b. Issue of the DODISS to be cited in the solicitation, and, if required, the specific issue of individual documents referenced (see 2.1.1, 2.2), c. Page integrity requirements (see 3.4), d. Output file requirements (see 3.5), e. Special features (see 3.6), f. Spell checking and hyphenation (see 3.6.1 and 3.6.2), and g. Data content notations not included in appendix C. 6.3 Application of non-Government standards. Current national and international non-Government standards do not adequately address all seven steps of the publication preparation process (see 6.1). ISO 8879 addresses steps a and c. Appendices A, and C of this specification provide a common DoD-wide implementation of ISO 8879. IS 10180 supports step g. No approved national or international standards exist to support steps b and e. Work is underway to define an international Document Style Semantics and Specification Language (DSSSL). As work matures in these areas, this specification will be extended or companion military specifications will be developed to define their implementation and application within DoD. In the interim, appendix B of this specification supports steps b and e of the publication preparation process (6.1). 6.4 Baseline publication types. The many types of technical publications in the DoD inventory are developed to numerous specifications and contract requirements. Technical manuals, which constitute one major category of technical publication, contain instructions for the installation, operation, maintenance, training, and support of weapon systems, weapon system components, and support equipment. 6.4.1 MIL-M-38784 application. In most cases, MIL-M-38784 is used to define the general structure, format, and style requirements for development of technical manuals. However, MIL-M-38784 is not explicitly cited but rather is imposed through use of one of the content/detail specifications. Technical publications may not conform to general structure, style, or format conventions; either because deviations have been explicitly authorized or because the specification(s) requirements allow the author latitude in these areas. Text markup procedures must provide the flexibility to accommodate options allowed by the specifications. 6.4.2 General application. A second objective of this specification is to provide guidance for the user in developing document type declarations for technical publications controlled by military specifications or specific contract requirements. This would be accomplished by defining a set of SGML elements, attributes, entities, and other SGML constructs applicable to the non-standard publication. Appendix A, section 50, provides a document type declaration set to be used as an example for development of document type declaration sets. Accordingly, this specification, including its appendices, will support most automated publishing applications within the Department of Defense. 6.4.3 SGML document type declaration sets. For preparation of technical publications, the document type declarations set contained in the appropriate detailed specifications currently listed in the DODISS shall be used. When a document type declaration set has not been developed for a specification, when deviations from the requirements of these specifications have been authorized, or when the requirements of these specifications must be interpreted differently, an alternative document type declaration set must be developed and delivered. appendix A, section 50, provides an example document type declaration set that may be used as a guide for development of alternative document type declarations. This example document type declaration set shall not be used to deliver data to the government. 6.4.4 Formatting Output Specification Instance (FOSI). An objective of the FOSI is to rigorously define the format and style of the document produced from the SGML-tagged text. Together with the markup tags specified in the document type declaration set, the FOSI provides a basic vocabulary from which changes in output processing statements (macros) can be constructed. 6.4.5 Page description languages (PDL). While a FOSI defines format and style requirements for a technical publication, specific electronic publishing systems may define additional processing limitations, such as font variations, kerning, or hyphenation. International Standard IS 10180, Information Technology - Text Communications - Standard Page Description Language (SPDL), can be used to ensure that the composed document produced by the electronic publishing system would produce nearly identical hardcopy output on the widest possible spectrum of printer devices. Even then, additional content or processing restrictions may be needed. 6.4.6 Specification revisions. Future revisions to this specification will broaden its application on a cost-effective basis. This may be accomplished by: a. including in appendix A additional SGML markup tags; and b. including in appendix B additional format and style options consistent with any changes made to future appendices. Further, examination of military specifications and standards governing preparation of technical publications may identify requirements which cannot be satisfied without such additions. Users are encouraged to submit suggestions for update of this specification to the Preparing Activity. Procedures for registration and control of support files for technical publications will be established. This specification addresses automated publishing and softcopy (on-screen display) requirements for page-oriented technical publications. Automation requirements for non-page oriented (pageless) technical publications will be addressed in a separate military specification. Additional material may be incorporated in this specification in the future to ensure that requirements for both page-oriented and pageless technical publications remain compatible and consistent. Through its TMSS (Technical Manual Specification and Standards) program, the Department of Defense is consolidating the large number of military specifications currently used to define functional requirements for page-oriented technical publications. Through revisions to this specification or additions to the consolidated functional specifications, DoD will implement automated publishing requirements for the consolidated set of TMSS requirements documents. DoD objectives are to: a. Have a minimum number of TMSS to address most DoD functional requirements for technical publications. b. Support the consolidated set of TMSS documents with a minimum number of document type declaration sets and FOSIs to address most DoD automated publishing requirements for technical publications. These objectives will be achieved in an evolutionary fashion. They will result in publication of new TMSS specifications to replace those currently in use, and corresponding updates to this specification. Development of document type declarations and FOSIs to meet common DoD requirements will be prioritized. Users are encouraged to assist in establishing the priorities for these document type declarations and FOSIs, and to make use of them as they become available. Unless otherwise specified, development of program-specific document type declarations and FOSIs is prohibited. 6.5 Publication management and processing considerations. 6.5.1 Technical publication management considerations. This specification provides the contractor and Government technical publication manager with tools to be used in determining if a given document is in or out of conformance with the governing specification, or contract requirements. 6.5.1.1 Preparation of document type declaration sets. Constructing and maintaining SGML document type declaration sets in accordance with FIPS PUB 152 is necessary to facilitate the automated preparation, storage, retrieval, interchange, and processing of technical publications. The technical publication manager must maintain full control over the technical publication's structure, content, and format. When no standard, publicly identified document type declaration set is available, or an available one is not applicable, an alternative document type declaration set must be prepared. Even when a specification having an applicable, publicly identified document type declaration set is contractually cited, the resultant technical publication may diverge from its requirements for a variety of reasons: a. Military specifications such as those cited are permissive with regard to precise document construction, and contain language giving precedence to contract provisions. b. Authors often write to multiple military specifications in a given document (when these specifications are cited in the contract), or to specific statement of work requirements, and these requirements may conflict with or override the specifications. Consequently, there are legitimate reasons why the publicly identified document type declaration sets are not applicable. However, where a cited specification having a standard document type declaration set is contractually required, the Government technical publication manager should carefully weigh the implications before defining unique requirements which would preclude use of that document type declaration set. It is an objective of this specification to minimize the number of unique document type declaration sets that must be created, managed, and maintained. This objective will be met through control of requirements by the Government technical publication manager. 6.5.1.2 Identification of Document Type Declaration Sets. In document type declaration sets contained in content specifications, the public identifier of the original version of a given DTD will consist of the specification identifier (e.g. MIL-M-12345). Subsequent revisions of a specification will consist of a specification identifier including the revision letter (e.g. MIL-M-12345A). Amendments to specifications will be indicated by the term "AMEND n" where 'n' is a number (e.g. MIL-M-12345A AMEND 1). 6.5.1.3 Use of document type declaration sets. The appropriate SGML document type declaration set provides a basis for electronically preparing a given publication, and then determining whether the document conforms to the logical constructs within the document type declaration. A syntactic analysis is made by parsing the document. Parsing will verify whether or not the string of tokens conforms to the grammar. 6.5.1.4 Page integrity. Page integrity is one technique for maintaining configuration control of technical publication changes. Page integrity is also used to support a loose-leaf or page update printing and distribution system for applications which require it. Both of these objectives are different from document-specific page formatting, in which page breaks are used to assist in communicating the information content of the publication. The requirement for page integrity is optional, and should be carefully evaluated in terms of cost and utility. 6.5.2 Processing system considerations. The processing system is a tool of the author and the technical publication manager. The processing system should not abrogate the authority of the manager to: a. determine whether document corrections are warranted, and b. set an orderly plan and schedule for such correction. Likewise, the author's authority over interpretation of contract requirements for content, style, and format should not be abrogated by the processing system unless expressly authorized by the technical publication manager. 6.5.2.1 Source file configuration control. Ideally, the processing system should have the capability to utilize the SGML-tagged source file (plus illustration files) as input to the subsequent composition and output processes. However, this is not a requirement, and intermediate files may be used. Configuration control of changes to either intermediate or output files is necessary, since the final deliverable product is the SGML-tagged source file. All system processing should be governed by the following rule: When corrections are made to a working, intermediate, or output file, corrections must be incorporated in the source file which is the primary final deliverable product under the contract. 6.5.2.2 Spell checking and hyphenation. Hyphenation rules are already established for specifications having FOSIs. For those instances where FOSIs must be developed, as per the contract see, appendix B 40.1.1. 6.5.2.3 Processing instructions. Processing instructions are a tool provided by SGML to handle unique or unusual conditions. Their use is discouraged, but not disallowed, because it is recognized that in some situations processing instructions are a necessary part of document processing. They are usually system-unique and are ignored by an SGML parser, precluding all control except cursory syntax checks unless additional processing system software is used. 6.5.3 Electronic review. The declaration set specified in appendix C, section 80, provides the required SGML structures for the review of SGML text documents electronically using SGML for the comments. The capability supported by these structures enables reviewers located in diverse environments to make and exchange comments to multiple copies of a document file over a network. The comments may then be sorted, processed, and incorporated into the document by the "owner" system. 6.5.3.1 Electronic review process improvement. This capability represents a process improvement over the traditional document development process: a. The use of SGML throughout the entire document development cycle eliminates "redline" paper copies and costly conversion cycles that typically occur during document development. b. The benefits of the SGML intelligent markup remain accessible throughout. c. Time required for delivery and review cycle is reduced. d. Text and graphics are maintained in discrete files under their originating processes, facilitating reuse. 6.5.3.2 Electronic review comments. Electronic review comments are distinguished from comments made using proprietary vendor annotation capabilities by the following characteristics: a. The comments may be associated with text elements at any level in the document structure. b. The comments may be shared between different workstations. c. The comments are machine-processable for a variety of purposes, some of which may be user-defined. 6.5.3.3 Electronic review declaration set. The declaration set specified in appendix C, section 80, consists of a portable electronic review "toolkit" suitable for incorporation into any document type declaration, for use in review of any document instance of that type. The structures have been defined as generically as possible, in order to take many kinds of review into account: (e.g., internal contractor reviews, Government reviews, contractor/Government reviews, and specification reviews.) Provision has been made for the definition of user-defined values for categories of review information. Additional thought has been given to processing scenarios involving use of the declaration set on a range of platforms, with automation of functions supported by the SGML structures varying to great degree. Consequently, the declaration set has been designed to support the preparation of comments (modification requests, or modreqs) that may be stored in either of the following ways: a. Within a modreq-only document that references the base document instance. b. Within the base document instance to which the modreq refers. 6.5.4 Interim deliverables. An interim deliverable is a delivery source of SGML data that is accomplished prior to the final delivery where all SGML data is included. This is the case for documents that may be submitted for an in-process review where the document is expected to be only partially complete when submitted. Source files are only one form of interim deliverable that may be contractually required. The cost and schedule implications of early transmission of processable source data should be carefully evaluated. Partial source documents may be used as an interim deliverable and should be used as an update mechanism for documents that have already been delivered. Delivery of partial documents for either purpose must conform to the following description of partial document delivery methodology. 6.5.4.1 Partial document delivery. Partial document delivery is used to transmit SGML source data either as an interim deliverable or as an update package for a document that has been previously delivered. Its purpose is to minimize the retransmittal of unchanged data, or to indicate data that is incomplete. Partial document delivery is not intended to address the issues of page integrity or fidelity, nor is it intended to address specific change pages. The intent of this methodology is to allow the transmission of portions of a source document such that the receiving system can identify the location of the information in the original document and perform the appropriate add, delete or replace operation. The manner in which this is accomplished and the effect of the change on composition is up to the receiving system and should reflect the requirements called out in the controlling specifications. 6.5.4.1.1 Concepts. The method of reliable interchange of SGML source data relies on the concept of a document map. The document map is an SGML document entity that contains the high-level element hierarchy of the document, but little actual text other than perhaps the content of the idinfo element or other such identifying information. Elements of the hierarchy that are not being transmitted contain a special attribute to indicate that they are not being transmitted. Elements that do contain text to be updated are represented by references to external entities that contain the actual changed elements. In order to facilitate the automated update of the information the sender and receiver should agree to the elements that should be modularized as separate entities. It is best if this agreement is made part of the contract. This is not mandatory, however, and using this methodology a receiving system should be able to identify all information and map it to data in it's system. Other attributes of the elements indicate the operation of add, replace or delete. The use of the document map accomplishes two objectives: 1) the file may be parsed and validated for conformance to the required DTD without expecting errors, and 2) the map is used as a locator for the changed information in the original document. The file(s) containing a document map is (are together) known as the Transmittal Master for the document. 6.5.4.1.2 Transmittal Master. The transmittal master file is a map of the document hierarchy. All significant elements of the DTD, as seen in the following example, have a special attribute of type CONREF. When specified, CONREF attributes have the behavior of causing the content of an element to be treated as EMPTY. No data is allowed as content to an element that has a CONREF attribute specified. This behavior indicates portions of a document that are not being transmitted. By using the CONREF attribute at the highest level of the hierarchy at which no data is to be transmitted. The actual data can be omitted and result in no errors. In fact one must NOT include any data in that hierarchy or a validation error will result. Elements of the hierarchy that are not being delivered, are not required to locate a specific instance of an element, and are not required for the transmittal master to parse against the DTD need not be included in the transmittal master. The simplest use of this technique can be described with an example in which we are delivering the third chapter of a multi-chapter document. The tag for all chapters that are NOT being delivered uses the defined attribute and no content. The one chapter that has content does NOT use the attribute and is treated normally. A mark-up example follows for a transmittal master and its included file. Note, since there is no data in the fourth chapter being delivered, the chapter's SGML markup is not actually needed since it is not required to sequence any other code. If a fifth chapter were being delivered, then the fourth chapter's markup is required. ]> TO43D3-2-5-31 OPERATION AND MAINTENANCE INSTRUCTIONS TRAINER FLIGHT SIMULATOR A/F37A-T56 (B-52G) NORTH STAR CORPORATION F12345-92-D-1234 Published under authority of the Secretary of the Air Force 4 OCTOBER 1983 &chap3; The referenced entity (chap3) may look like the following example: MAINTENANCE TASKS <section> <title>DISASSEMBLY <para0 id='p104'><title>Engine Information. <para>The engine engages with the shaft key before the finger assembly closes. This spool must be oriented so that the film unwinds from the under side of the spool. <subpara1><title>Loading the Film Magazine. <para>Feed the film through the magazine at a 25 degree angle and onto the take-up spool a shown in figure <xref xrefid='f223' xidtype='figure'>. (This figure is also reproduced on the mechanism cover.) <subpara1 stub="stub"> </section> <section stub="stub"> The example shown assumes interchange of data at the chapter level. The same methodology would be used to exchange data at a lower (para0) or higher (body) level. References to graphics in the transmitted files must be resolved by defining the appropriate entities in the declaration subset. The transmittal master may include only the graphic entity declarations for graphics submitted as changed parts of the document. The minimum requirements for partial delivery of SGML documents are: a. Delivery of the transmittal master file at each delivery. The complete content of module elements shall only be transmitted for those modules containing changes; all other module elements shall be nulled with STUB attributes, and b. Placement on transmittal media in accordance with MIL-STD-1840 applicable conventions. 6.5.4.2 Additional final deliverable. Life cycle maintenance of the technical publication requires delivery of the source file (and support files, if appropriate) as a final deliverable. However, contract requirements may specify that a page description language file be delivered as an optional, additional product. 6.6 Technical publication data requirements. When this specification is cited in a contract, a contract exhibit must be prepared to fully describe statement of work criteria and delivery instructions, and cite this and any other applicable specifications. 6.7 Definitions. 6.7.1 Acronyms. Acronyms used in this specification are defined as follows: a. ATA Air Transport Association b. DoD Department of Defense c. DODISS Department of Defense Index of Specifications and Standards d. DSSSL Document Style Semantics and Specification Language e. DTD Document Type Definition f. FOSI Formatting Output Specification Instance g. OS Output Specification h. PDL Page Description Language i. SAE Society of Automotive Engineers j. SPDL Standard Page Description Language k. SGML Standard Generalized Markup Language l. TM Technical Manual m. TMSS Technical Manual Specification and Standards 6.7.2 Glossary. 6.7.2.1 Definitions for SGML constructs. These definitions are based on those available in ISO 8879 and are repeated here for convenience only. For a complete glossary of terms, see ISO 8879, clause 4. 6.7.2.2 Attribute (of an element). A characteristic quality, other than element_type or content. 6.7.2.3 Attribute definition. A member of an attribute definition list within an attribute list declaration; it declares an attribute name, specifies the form and SGML-specific aspects of possible values, and specifies the action (such as providing a default value) to be taken if an attribute's value is not specified. In the display under ATTRIBUTE (DEFINITION) LIST DECLARATION, each attribute definition is shown as: name_of_attribute allowable_values default 6.7.2.4 Attribute (definition) list declaration. A markup declaration that associates an attribute definition list with one or more element types, shown as: <!ATTLIST name_of_associated_element(s) name_of_attribute allowable_values default name_of_attribute allowable_values default name_of_attribute allowable_values default> 6.7.2.5 Attribute (specification) list. Markup that is a set of one or more attribute specifications, shown as: attribute="value" attribute="value" attribute="value" Used within a Start Tag, as in: <element_name attribute=value attribute=value attribute=value > 6.7.2.6 Declaration. Markup declaration. 6.7.2.7 Declaration subset. A delimited portion of a markup declaration in which other declarations can occur. 6.7.2.8 Document type declaration. A markup declaration that contains the formal specifications of a document type definition, shown as: <!DOCTYPE document_type_name optional_external_identifier [ optional_document_type_declaration_subset ] > 6.7.2.9 Document Type Definition (DTD). An abstract collection of rules, determined by an application, that apply SGML to the markup of documents of a particular type. 6.7.2.10 DTD. Document type definition. (NOTE: "DTD" is occasionally--but not in compliance with ISO 8879 terminology--used as an abbreviation for "document type declaration"; it is also an SGML reserved word used in formal public identifiers to indicate that the identified entity is a document type declaration set, and is often used to identify such a set.) 6.7.2.11 Element. A component of the hierarchical structure defined by a document type declaration. It is identified in a document instance by descriptive markup, usually a start-tag and end-tag, shown as: <element_type_name attribute=value attribute=value>content of the element</element_type_name> 6.7.2.12 Element type declaration. A markup declaration that contains the formal specification of the part of the definition of an element type that deals with the content and markup minimization, shown as: <!ELEMENT element_type_name start_tag_minimization end_tag_minimization content_model_or_declared_content> 6.7.2.13 Entity. A collection of characters or other data that can be referenced as a unit. 6.7.2.14 Entity declaration. A markup declaration that assigns an SGML name to an entity so that it can be referenced, shown as: <!ENTITY entity_name entity_text> 6.7.2.15 Entity reference. A reference that is replaced by an entity, shown as: &entity_name; or %entity_name; The ampersand is used for general entities (referenced in the document element); the percent sign is used for parameter entities (typically referenced in the document type declaration). 6.7.2.16 Entity set. A set of entity (and comment) declarations that are used together. 6.7.2.17 Output file. A text presentation metafile developed through use of a PDL. 6.7.2.18 SGML. Standard Generalized Markup Language, as detailed in International Standard 8879. It is a metalanguage that provides a coherent and unambiguous syntax for describing whatever a user chooses to identify within a document. 6.7.2.19 SGML declaration. A markup declaration that specifies the character set, concrete syntax, optional features, and capacity requirements of a document's markup. It applies to all of the SGML entities of a document. 6.7.2.20 SGML entity. An entity whose characters are interpreted as markup or data in accordance with ISO 8879. 6.7.3 Definitions for terms created for or used by this specification. 6.7.2.1 Declaration set. A set of declarations that are used together. 6.7.3.2 Document type declaration set. A declaration set intended for inclusion within a document type declaration. It consists of one or more entity sets and/or element type sets and/or short reference sets. (NOTE: Short reference declarations are not currently used in documents covered by this specification.) 6.7.3.3 Document type declaration subset. The declaration subset of a document type declaration. It consists of a document type declaration set. (NOTE: This definition has been modified to incorporate the semantics employed by this specification. It has, therefore, been included in this subsection.) 6.7.3.4 Element type set. A set of element type, attribute list, and notation (and comment) declarations that are used together. 6.7.3.5 Formatting Output Specification Instance (FOSI). An instance of the Output Specification (OS) that assigns values to the style characteristics for a particular document type declaration. The FOSI uses the syntax of an SGML document instance. 6.7.3.6 Output Specification (OS). A finite set of style characteristics to convey formatting intent for interchange of technical publications coupled with a mechanism for binding the style characteristics to logical elements in an SGML document type declaration. The OS uses the syntax of an SGML document type declaration. 6.7.3.7 Page fidelity. The ability to preserve the exact presentation characteristics in addition to the same information on pages exchanged between systems. 6.7.3.8 Page integrity. The ability to preserve the exact same information on each page in a manual as it is exchanged between systems. This does not mean that the information will be presented exactly the same way, but only that it appears between the same page boundaries. 6.7.3.9 Technical publication verification. This term refers to the parsing of the digital data stream containing a technical publication to assure compliance with the standard (SGML, CCITT, CGM, IGES) to which it was written. There is no intent in this term to imply the validation/verification process used to certify the content of the technical publication. 6.8 Subject term (key word) listing. The following subject terms (key words) are applicable: Language, Page Description Manuals, Technical Orders, Technical Page Description Language Publications, Technical Publishing, Electronic Standard Generalized Markup Language Tagging, Generic Text Composition Language Text Presentation Metafile Document Type Definition (DTD) Formatting Output Specification Instance (FOSI) Output Specification (OS) 6.9 Changes from previous issue. Marginal notations are not used in this revision to identify changes with respect to the previous issue due to the extensiveness of the changes. EXAMPLE DOCTYPE FOR TECHNICAL DOCUMENTS MARKUP TAGS 10. SCOPE 10.1 Scope. This appendix describes the role played by Document Type Declarations in an SGML implementation. It provides a general description of document type declaration structure and content, as well as an example document type declaration set with element and attribute set descriptions. They may be used as guidance in the development of document type declarations. When specified by the acquiring activity, this appendix is a mandatory part of this specification. The information contained herein is intended for compliance. 20. APPLICABLE DOCUMENTS 20.1 Applicable documents. This section is not applicable to this appendix. 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 the SGML Declaration. 30.2 ISO 8879 - background. 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 definition, 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 subsequently be processed for braille delivery, on-line screen delivery, audio delivery, machine-to-machine delivery, paper delivery, database 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, mathematical 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 logically structured document to serve the most diverse needs. 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 straight forward 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 database definition available for reference. To remedy that situation, it is necessary to devise a way to describe the unfielded database 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 6.7.2.8). 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. SGML description: <!DOCTYPE memo [ <!ELEMENT memo - - (front, body)> <!ELEMENT front - o (date, receiver+, author+, cc*, bc*, rdate?, subj, abstract?)> <!ELEMENT body - o (para+)> <!ELEMENT (date | rdate) - o (day, month, year)> <!ELEMENT (receiver | author | cc | bc) - o (name, pos, mailstop)> <!ELEMENT mailstop - o (code, num)> <!ELEMENT (day | month | year | name | pos | code | num | subj | abstract | item) - o (#PCDATA)> <!ELEMENT para - o (#PCDATA | list)+> <!ELEMENT list - o (item+)> ]> 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 a military specification, tens or possibly hundreds of pages are devoted to a description of both the logical structure and the format of 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. 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 <! and end with a markup declaration close of >. A declaration that will be used throughout this discussion is the comment declaration, shown as: <!-- comment text -->. 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: <!DOCTYPE document_type_name optional_external_identifier [optional_internal_subset]> The document type declaration subset contains the other declarations, explicitly within the internal subset (or within a document type declaration set incorporated by reference therein) or within the external subset, which is a document type declaration set identified by the external identifier and incorporated by implicit reference after the internal subset. 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: <!NOTATION notation_name notation_identifier > 30.4.3.3 Entity declaration. An entity declaration follows the form: <!ENTITY entity_name entity_text > The entity text is the information needed to identify the entity. It may be a quoted version of the entity's content or a quoted string identifying an entity whose content is located elsewhere. The entity's content is the real `text' of the entity: that text that directly replaces a reference to the entity when the reference is detected during parsing. The entity's content may be additional SGML text or non-SGML data. If it is non-SGML data, the content must be located externally to the declaration and an appropriate data content notation must be specified. Entities whose content is specified directly in the declaration are called "internal"; those whose content is located externally are called "external". External entities in some sense have an existence of their own and may be declared and referenced in many documents. This will be discussed further in 30.4.4. 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 declaration is: <!ENTITY dod "Department of Defense"> The entity would be referenced with: &dod; Parameter entities are declared in the document type declaration also. However, such entities are referenced within other declarations, 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: <!ENTITY % text "(#PCDATA | ftnref | indxflag | verbatim | xref | graphic | subscrpt | supscrpt | tool | testeq | material | torqueval | dataiden | hrule | emergency | change | emphasis | applicabil )"> The entity is referenced with: %text; General entity names can be 32 characters long (when using the SGML declaration prescribed in 6.1.1 of this specification. Parameter entity names can be 31 characters long (again, when using the SGML declaration of 6.1.1). Summary: A parameter entity declaration has a percent sign and additional whitespace preceding the name of the entity; a general entity does not. A parameter entity reference opens with a percent sign immediately preceding the entity name, and a general entity reference opens with an ampersand. Both types of entity reference are normally terminated by a semicolon immediately following the entity name. 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). It is best to always terminate an entity reference with a semicolon. 30.4.3.4 Element type declaration. To describe how and when elements may occur, SGML makes use of element type declarations. Declarations contain the name of the element type or a parenthesized group of element type names, the start- and end-tag minimization that may be used, 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 cases, 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 document type declaration are allowed, as well as parsed character data). Parsed character data (PCDATA) may also be specified in a content model. Additionally, exceptions may be part of the content model. 30.4.3.4.1 Model group. A model group is a list of element type names and/or the identified keyword "PCDATA" (written as "#PCDATA" to distinguish it from the element name "PCDATA"), and/or smaller model groups, enclosed in group delimiters, parentheses. a. Use of connectors. Elements listed within a group are separated by connectors. There are three types of connectors: (1) 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; (2) 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 (3) 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: <!ELEMENT book - - (front, body, rear?)> <!--A book is made up of the elements front, body, and rear, each occurring in that order. --> <!ELEMENT front - - (title & author)> <!--The front matter of the book is made up of a title and author; however, either one may occur first. --> <!ELEMENT body - - (chapter | section)> <!--The body is made up of either a chapter or a section, but only one can occur.--> <!ELEMENT title - o (#PCDATA)> <!--A title is made up of parsed character data; no further subdivision of elements is allowed. --> <!ELEMENT rear - - ((appendix & index), (biblio | glossary)) > <!--Both an appendix and an index must occur; either one may occur first, the other immediately afterward. Following them, either a bibliography or a glossary must occur, but not both. Notice that each type of connector is used in a different group. One group is "(xxx & yyy)." Another group is "(xxx | yyy)." A third group is "((xxx), (yyy))." In this last example, the comma is connecting two groups rather than two element type names. Connectors can also be used between element types and groups, such as: (xxx, (yyy)). The last two examples also illustrate that a group may have only one element type name within it. --> b. 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: (1) The "opt" (optional) occurrence indicator, the question mark (?), indicates that the element type or group may occur zero or one time; (2) The "plus" occurrence indicator, the plus sign (+), indicates that the element type or group must occur once, but may be repeated; (3) The "rep" (repetition) occurrence indicator, the asterisk (*), indicates that the element type or group may occur zero or more times; and (4) No occurrence indicator means that the element type or group must occur once and only once. Some examples follow: <!ELEMENT book - - (front, body, rear?) > <!--The front and body element types each must occur only once, but the rear is optional. --> <!ELEMENT front - - (title & author+) > <!--There is one title allowed and at least one author must be specified; however, there may be more than one author. The title can be specified first and then the authors or all authors may be specified and then the title. --> <!ELEMENT body - - (chapters+ | sections+) > <!--The body of the book may be made up of one or more chapters or one or more sections. --> <!ELEMENT title - o (#PCDATA) > <!--#PCDATA consist of zero or more characters. Any general entities are recognized and expanded while parsing #PCDATA.--> <!ELEMENT rear - - ((appendix+ & index)?, (biblio | glossary)?) > <!--The rear may or may not have a grouping of appendices and an index, but it may not have one without the other. Further, it may have more than one appendix, but only one index. All of the appendices or the index may occur first. Then, either a bibliography or a glossary may optionally occur. If the group had been specified as (biblio | glossary)* or (biblio | glossary)+, it would have meant that the group could be evaluated multiple times. This would mean that multiple bibliographies, multiple glossaries, one of each, or multiples of both might have occurred in any order. Also notice that both groups "(appendix+ & index)?" and "(biblio | glossary)?" comprising the content of the rear element type are optional so that it is possible for the content of rear to be nothing. This is not ambiguous and, therefore, acceptable. --> 30.4.3.4.2 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 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, <!ELEMENT ftnote - - (%list; | paratext)-(ftnote | table)> 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.4.3 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 start-tags and end-tags of various elements within a document. It should be noted that start-tag omission is discouraged (except for the "mathpac" tags) in CALS DTDs. 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: <!ELEMENT doc - - (front, body, rear) > <!ELEMENT front - - (titlepg, contents) > 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. A second example demonstrates the reverse of this in effect: <!ELEMENT safesum - o (para?, list, para) > <!ELEMENT para - o (biblio | glossary) > <!ELEMENT list - - (item+) > 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 a paragraph 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.5 Attribute list declaration. The last type of declaration is the attribute list declaration. <!ATTLIST element_name attribute_definition_list > 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 sample application of this specification, security classification is one of the attributes of many types of elements. A simplified version follows: <!ATTLIST doc security (u | c | s | ts) "u" service (af | army | navy | dla | cg | mc) #REQUIRED change NUMBER "0" > specifies that "u" (unclassified) is the default if the attribute is not specified for any particular element of that type. The second attribute is service. It lists six possible values and, through the use of the REQUIRED keyword, requires that one of them be specified. If it is not specified, an error will be reported as there is no default. Other default value keywords include IMPLIED (the value is implied by the application) and CURRENT (required on the first usage of that attribute for that element type, defaults to previous value on all subsequent usage for that element type). The third attribute is the change level. Its value must be a number. The default is "0". An attribute's declared value can be of the following types: a. CDATA: Any usable characters as defined by the SGML declaration. b. 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) as well as "-" and "." for the rest of the characters. c. NAMES: One or more NAME separated by one or more parameter separator characters -- space, tab, record end, etc. d. NMTOKEN: Begins with and contains name characters. e. NMTOKENS: One or more NMTOKEN. f. NUMBER: All digits, conforms to NAMELEN. g. NUMBERS: One or more NUMBER. h. NUTOKEN: Begins with a digit and then contains name characters. i. NUTOKENS: One or more NUTOKEN. j. ENTITY: Syntactically conforms to NAME and refers to a declared, externally defined SDATA, CDATA, or NDATA entity. k. ENTITIES: One or more ENTITY. l. ID: A unique identifier conforming syntactically to NAME. m. IDREF: References an ID. n. IDREFS: One or more IDREF. ISO 8879, should be consulted for a complete list. 30.4.4 External entities. External entities are commonly used entities kept separate from the declarations. The entity declaration simply contains a special identifier, either publicly known or known only to a particular system. 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 often (although technically incorrectly) called a "DTD." 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 Uses of entities. 30.5.1 Shorthand. Entities are sometimes used just as shorthand for character strings that are used often within a document, either in the document element itself or within the declarations occurring or referenced within the document type declaration. The examples in 30.4.3.3 would probably be used this way. 30.5.2 Modularization. External entities are often used for modularization. A module, in this sense, is a portion of a document which is maintained separately, either for administrative convenience or for reuse. A document type declaration set kept in an external entity and referenced in many documents document type declarations is perhaps the most pervasive use of modularization. (Such a declaration set is often in the common vernacular called a "DTD", although technically "DTD" or "document type definition" is a slightly different concept.) Even these sets are themselves modularized; for example (see the "example DTD" later in this appendix), subcollections of declarations are often separated out into reusable modules that can be incorporated by reference into many "DTDs". The "math pack" and the special character sets found in appendix C are examples of such reusable modules. They were created by the International Organization for Standardization (ISO) and are incorporated into many DoD DTDs. In addition, the special character set modules may be referenced directly in the internal subset of a document's document type declaration, if the DTD used does not include it and some of it's special characters are needed in the document. Modules to be incorporated by reference within a document type declaration must be declared within that declaration before they can be referenced. It is sometimes useful to modularize a document even when there is no intent to reuse the modules. For example, it might be useful to place the chapters of a document into separate modules so that one writer can work on each chapter independently of the others. This sort of modularization is one of the primary techniques used to handle partial document transmissions (described elsewhere in this specification). Reusable standard text can also be placed in modules; there are many such modules in appendix C, Section 80. 30.5.3 Parametrization of modules. A reusable module entity can often be made more useful if there is a way to routinely tailor certain phrases within the standard text or standard declarations therein. This is done by placing an entity declaration within the content of the module entity. For example, a public entity has been created for distribution notices. The following text is the content of a standard text entity excerpted from appendix C: This publication is required for official use or for administrative or operational purposes only. Distribution is limited to U.S. Government Agencies. Other requests for this document must be referred to &distrib1;. This entity can be referenced within a document, but in order for it to be used, the &distrib1 entity must first be declared. That is done on a document-by-document basis, using a declaration such as <!ENTITY distrib1 "AF/XYZ, The Pentagon, Washington, D.C" > in each document's document type declaration internal subset. If &distrib1 is not declared, the standard text entity will not parse if referenced within a document. Calling an entity reference such as that to &distrib1 in the standard text entity just shown a "parameter" does not mean that the entity is a "parameter entity". These are two different meanings of the word "parameter". Generally, we will speak of "parametrization", but will try to avoid using this non-SGML meaning of "parameter". 30.5.4 Default values for parameters. In order to insure that documents using this standard text entity will parse, even if &distrib1 is not correctly declared, a default declaration for &distrib1 is also provided in Appendix C (although its text will surely not be what is desired). This declaration and a declaration for the standard text entity are packaged up into a module that can be referenced within the document type declaration; the default declaration will be ignored if another correct, declaration is encountered first while parsing the document type declaration that includes them both. <!ENTITY distrib "This publication is required for official use or for administrative or operational purposes only. Distribution is limited to U.S. Government Agencies. Other requests for this document must be referred to &distrib1;."> <!ENTITY distrib1 "Originator Supplies Applicable Activity or Address Here"> The document type declaration sets created in accordance with this specification are often heavily parametrized. This permits a document type declaration set module to be reused for slightly different but related types of documents. 30.5.5 Graphics and other non-SGML data entities. Graphics and other non-SGML data may be identified for use within an SGML document through the use of notation and external entity declarations. (Currently there are no approved non-graphic notations.) Notation declarations define a type of data content and supply an external identifier which gives information about processing such content. External non-SGML entity declarations identify the entity to be included and specify the notation by which the entity content is to be interpreted. 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 internal 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. <!DOCTYPE doc PUBLIC "-//USA-DOD//DTD MIL-M-12345//EN" [ <!NOTATION iges PUBLIC "-//USA-DOD//NOTATION Initial Graphics Exchange Specification//EN"> <!ENTITY board1 SYSTEM NDATA iges> <!ENTITY board2 SYSTEM NDATA iges> ]> Alternatively, some graphics may be publicly identified and would be declared using their public external identifier: <!DOCTYPE doc PUBLIC "-//USA-DOD//DTD MIL-M-12345//EN" [ <!NOTATION fax PUBLIC "-//USA-DOD//NOTATION CCITT Group 4 Fax"> <!ENTITY calslogo PUBLIC "-//USA-DOD//NONSGML CALS LOGO//EN" NDATA fax> ]> 30.6 Guidelines for document type declaration creation. 30.6.1 Choosing the appropriate document type declaration set. The detail specifications should contain document type declaration sets for the content and structure of documents produced in accordance with that specification. Appendix A contains a sample document type declaration set which may be used to construct the document type declaration when one is not provided within the detail specification. In many cases, only the addition of a few entity declarations for specifying constant text or standard tables are required. 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 sample public document type declaration set. 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 entity is declared more than once, all subsequent declarations 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. A user of this sample 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: <!DOCTYPE doc PUBLIC "-//USA-DOD//DTD MIL-M-00001 //EN" [ <!NOTATION cgmchar PUBLIC "ISO 8632/2//NOTATION Character encoding//EN"> <!-- Declares that graphics can use the character encoding for CGM --> <!ENTITY figure1 SYSTEM NDATA cgmchar> <!ENTITY figure2 SYSTEM NDATA cgmchar> <!-- Declares there will be two graphics, each with the data content notation of "cgmchar" --> <!ENTITY % distrb PUBLIC "-//DOD-USA//ENTITIES DISTRIBUTION NOTICE 900102//EN"> <!-- Declares publicly defined text entities. --> <!ENTITY distrib1 "OO-ALC, Hill AFB, Ogden, UT 84056-5609"> <!-- Defines one of the text entities declared in the public set. --> %distrb; <!-- Makes public text entity set available for use. The original definition of `distrib1' is read in with this reference, but as it is the second definition of the entity, it is ignored. --> ]> 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 sample MIL-M-67890 public declaration set. In this way, the new public identifiers refer to a combination of the original sample public declaration set for MIL-M-12345 documents as well as the additional declarations that refer to the associated document type. The following is an example: <!-- The following set of declarations may be referred to using a public identifier, as follows: <!DOCTYPE doc PUBLIC "-//USA-DOD//DTD MIL-M-12345//EN"> --> <!ENTITY % frnt "(idinfo, lep, contents, iluslist?, intro)"> <!ENTITY % M67890 PUBLIC "-//USA-DOD//DTD MIL-M-67890 //EN"> %M67890; An example of the use of the public document type declaration might be: <!DOCTYPE doc PUBLIC "-//USA-DOD//DTD MIL-M-12345 //EN" [ <!NOTATION cgmchar PUBLIC "ISO 8632/2//NOTATION Character encoding//EN"> <!ENTITY figure1 SYSTEM NDATA cgmchar> <!ENTITY figure2 SYSTEM NDATA cgmchar> ]> 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 (M67890) for the original sample public declaration set for MIL-M-67890 documents, and a parameter entity reference (%M67890;) to that public declaration set (which in effect resolves, or includes, all of the declarations in the sample public declaration set for MIL-M-67890). The user then lists the entities particular to their document instance. The document type declaration set in appendix A, section 50 provides a model that can be used directly, or which more appropriately can be used as a sample for development of a document type declaration appropriate to a document whose structure conforms to other specifications. 30.6.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. 30.6.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 following entity declarations shall be associated with the public identifier: <!ENTITY % distrb PUBLIC "-//DOD-USA//ENTITIES DISTRIBUTION NOTICE 900102//EN"> To use and reference this entity set, use the public entity declaration in the declaration subset of the document type declaration to be used, followed by a parameter entity reference to the public entity: %distrb; --> <!ENTITY distrib "This publication is required for official use or for administrative or operational purposes only. Distribution is limited to U.S. Government Agencies. Other requests for this document must be referred to &distrib1;."> <!ENTITY distrib1 "Originator Supplies Applicable Activity or Address Here"> 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. <!DOCTYPE doc PUBLIC "-//USA-DOD//DTD MIL-M-12345//EN" [ <!ENTITY % distrb PUBLIC "-//DOD-USA//ENTITIES DISTRIBUTION NOTICE 900102//EN"> <!-- Declares publicly defined text entities. --> <!ENTITY distrib1 "OO-ALC/MMED, Hill AFB, Ogden, UT 84056-5609"> <!-- Defines one of the text entities in the public set. --> %distrb; <!-- Makes public text entity set available for use. The original definition of &distrib1; is read in with this reference, but as it is the second definition of the entity, it is ignored. --> ]> This document type declaration cites a 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 <notice> and not use &distrib;. 30.6.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: <!DOCTYPE doc PUBLIC "-//USA-DOD//DTD MIL-M-12345//EN" [ <!ENTITY % ISOgrk1 PUBLIC "ISO 8879:1986//ENTITIES Greek Letters//EN"> %ISOgrk1; ]> In this example, the public identifier in the document type declaration refers to the collection of declarations for the sample MIL-M-12345 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 Entity references are not recognized in CDATA declared element content. 30.6.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. <!DOCTYPE doc PUBLIC "-//USA-DOD//DTD MIL-M-12345//EN" [ <!NOTATION iges PUBLIC "-//USA-DOD//NOTATION Initial Graphics Exchange Specification//EN"> <!ENTITY board1 SYSTEM NDATA iges> <!ENTITY board2 SYSTEM NDATA iges> ]> Optionally, a literal string may be added to the declaration (see MIL-STD-1840): <!DOCTYPE doc PUBLIC "-//USA-DOD//DTD MIL-M-12345//EN" [ <!ENTITY board3 SYSTEM "System Data Identifying the Entity" NDATA iges> ]> Alternatively, some graphics may be publicly identified and would be declared using their public external identifier: <!DOCTYPE doc PUBLIC "-//USA-DOD//DTD MIL-M-38784 900102//EN" [ <!ENTITY calslogo PUBLIC "-//USA-DOD//NONSGML CALS LOGO//EN" NDATA fax> ]> 30.6.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.7 SGML declaration. The following SGML Declaration declares the character set, syntax, quantities, capacities, scope and feature of SGML to be used when interchanging SGML documents under this specification. Many of the quantities and capacities have been increased from the reference quantity andcapacity sets in ISO 8879 to enable DoD DTDs, FOSIs and Tagged Instances to parse without errors or warnings. <!SGML "ISO 8879:1986" CHARSET BASESET "ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0" DESCSET 0 9 UNUSED 9 2 9 11 2 UNUSED 13 1 13 14 18 UNUSED 32 95 32 127 1 UNUSED BASESET "ISO Registration Number 100//CHARSET ECMA-94 Right Part of Latin Alphabet Nr. 1//ESC 2/13 4/1" DESCSET 128 32 UNUSED 160 5 32 165 1 UNUSED 166 88 38 254 1 127 255 1 UNUSED CAPACITY SGMLREF TOTALCAP 32165152 ENTCAP 3000000 ENTCHCAP 3000000 ELEMCAP 3000000 GRPCAP 3000000 EXGRPCAP 3000000 EXNMCAP 3000000 ATTCAP 3000000 AVGRPCAT 3000000 IDCAP 3000000 IDREFCAP 3000000 SCOPE DOCUMENT SYNTAX SHUNCHAR CONTROLS 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 127 255 BASESET "ISO 646-1983//CHARSET International Reference Version (IRV) //ESC 2/5 4/0" DESCSET 0 128 0 FUNCTION RE 13 RS 10 SPACE 32 TAB SEPCHAR 9 NAMING LCNMSTRT "" UCNMSTRT "" LCNMCHAR "-." UCNMCHAR "-." NAMECASE GENERAL YES ENTITY NO DELIM GENERAL SGMLREF SHORTREF NONE NAMES SGMLREF QUANTITY SGMLREF ATTCNT 400 ATTSPLEN 960000 ENTLVL 1600 GRPCNT 320 GRPGTCNT 960 GRPLVL 1600 LITLEN 240000 NAMELEN 32 TAGLEN 960000 TAGLVL 240 FEATURES MINIMIZE DATATAG NO OMITTAG YES RANK NO SHORTTAG NO LINK SIMPLE NO IMPLICIT NO EXPLICIT NO OTHER CONCUR NO SUBDOC NO FORMAL YES APPINFO NONE > 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. When contract requirements 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 example document type declaration in appendix A, section 50, may be used as a template for document type declaration development. 50. EXAMPLE DOCTYPE FOR TECHNICAL DOCUMENTS <!-- The following set of declarations may be referred to using a public entity as follows: --> <!-- Depending on the software being used, the user may need to add the CALS SGML Declaration to this DTD or refer to it in an external reference --> <!-- The following set of declarations may be referred to using a public entity as follows: <!DOCTYPE doc PUBLIC "-//USA-DOD//DTD EXAMPLE REV B//EN" > --> <!-- NOTE: In order to parse the following Document Type Declaration Subset alone, append the Document Type Declaration statement below to the beginning of the file: <!DOCTYPE doc [ and the associated "]>" to the end of the file. --> <!-- ENTITY DECLARATIONS --> <!ENTITY % doc "volume+ | docpart+ | (front?, body?, rear?)"> <!ENTITY % docexpt "ftnote | pgbrk | brk | arbtext | hrule"> <!-- %service is the declared value of the service attribute of <doc>. It may be redefined to include additional or remove existing acceptable values for this attribute. --> <!ENTITY % service "af | navy | army | mc | dla | cg"> <!-- The %docatt entity may be redefined to provide additional attributes for the document level element as required.--> <!ENTITY % docatt 'service (%service;) #REQUIRED docid CDATA #IMPLIED version (basic | revision | change) "basic" docstat (prelim | draft | formal) "formal" mantype (standard | card | decal) "standard"'> <!-- MATH PACKAGE INCLUSION: To include the standard math package in a document, include in the document's document type declaration subset the following declaration: <!ENTITY % math "INCLUDE" >--> <!ENTITY % math "IGNORE" > <![ %math; [ <!ENTITY % mathpac PUBLIC "-//USA-DOD//DTD SUP MIL-M-28001 MATHPACK 911001//EN"> %mathpac; ]]> <!-- NOTE: Additionally required character sets must be explicitly designated in the document's document type declaration subset. --> <!-- The following entity is referenced in %text; --> <![ %math; [ <!ENTITY % mathtxt " | dfref | f " > <!-- only if %math; is "include" --> ]]> <!ENTITY % mathtxt "" > <!-- otherwise --> <!-- The following entity is referenced in %paracon; --> <![ %math; [ <!ENTITY % mathcon " | df | dfg " > <!-- only if %math; is "include" --> ]]> <!ENTITY % mathcon "" > <!-- ATTRIBUTE DEFINITION COLLECTIONS AND PARTS THEREOF --> <!-- Many attributes have a Boolean value. They are uniformly given the declared value "%yesorno;" rather than NUMBER to indicate this intent. 0 is interpreted as false; all other numbers as true. --> <!ENTITY % yesorno "NUMBER"> <!-- The itemid attribute group provides the ability to describe the text to which the attribute group pertains by the identifiers associated with the part to which the text refers. This group is also used within the standard body attributes (described below). --> <!ENTITY % itemid " sssn CDATA #IMPLIED unit CDATA #IMPLIED module CDATA #IMPLIED lru CDATA #IMPLIED assem CDATA #IMPLIED subassem CDATA #IMPLIED ssubassm CDATA #IMPLIED compon CDATA #IMPLIED partno CDATA #IMPLIED refdes CDATA #IMPLIED "> <!-- The content attribute group provides the ability to describe the text to which the attribute group pertains by the type of content, applicability, skilltrack, figures, and tables associated with the text. This group is also used within the standard body attributes (described below). --> <!ENTITY % content " texttype NUMBER #IMPLIED applictype IDREFS #IMPLIED applicrefid IDREFS #IMPLIED skilltrk NMTOKENS #IMPLIED contyp (desc | proc) #IMPLIED assocfig IDREFS #IMPLIED assoctab IDREFS #IMPLIED "> <!-- Some elements get a collection of attributes known collectively as body attributes. The %bodyatt entity contains all of the appropriate attribute definitions. --> <!ENTITY % bodyatt ' id ID #IMPLIED inschlvl NUTOKENS #IMPLIED delchlvl NUTOKENS #IMPLIED label CDATA #IMPLIED hcp %yesorno; "0" stub (STUB) #CONREF %itemid; %content; '> <!-- Many elements get a security-related collection of attributes. The %secur entity contains all of the appropriate attribute definitions. --> <!ENTITY % secur " security (u | c | s | ts) #IMPLIED restrict NMTOKENS #IMPLIED release NMTOKENS #IMPLIED codeword NMTOKENS #IMPLIED scilevel %yesorno; '0' diglyph NMTOKENS #IMPLIED "> <!-- %erptype is the declared value of the errptype attribute of <errpt>. It may be redefined to include additional or remove existing acceptable values for this attribute. --> <!ENTITY % erptype "tmder | afto22 | da2028"> <!-- %notctype is the declared value of the notctype attribute of <notice>. It may be redefined to include additional or remove existing acceptable values for this attribute. --> <!ENTITY % notctype " dist | auth | fouo | branch | pgclass | disclos | supersed | effdate | suppl | nopg | noclaspg | warning | destr | safesup | opersup | maintsup "> <!-- %sigtype is the declared value of the sigtype attribute of <sigblk>. It may be redefined to include additional or remove existing acceptable values for this attribute. --> <!ENTITY % sigtype "preparer | approval | review | concur | other"> <!-- ELEMENT TYPE COLLECTIONS AND MODEL GROUPS --> <!-- TITLES --> <!-- Some elements which have either required or optional titles may at times also require shortened forms of the title. If shortened titles are to be allowed in the instance then the parameter entity %shortitleuse; should be redefined as "include". --> <!ENTITY % shortitleuse 'IGNORE'> <![ %shortitleuse; [ <!ENTITY % shortitle ", shorttitle?">]]> <!ENTITY % shortitle ''> <!-- RUNNING TEXT --> <!-- Various numbers embedded in running text are tagged to permit easy identification for database work. They generally have no special display formatting requirements. --> <!ENTITY % nums " (partno | serno | partdesc | smrcode | nsn | modelno | sssn | refdes | docno | figindex | lin | faultcode) "> <!-- NOTE: regarding the adaptation of this document type declaration set for use with other document classes. Per the rules of FIPS PUB 152, regarding the timing of the resolution of parameter entities, the content of the following parameter entity cannot be used directly within a content model that occurs before the referenced are resolved, due to the parameter entity references within it. --> <!ENTITY % text " (#PCDATA | ftnref | xref | indxflag | verbatim | emergency | change | emphasis | applicabil | symbol | subscrpt | supscrpt | %nums; | tool | testeq | material | torqueval | extref | dataiden %mathtxt;)+ "> <!-- PARAGRAPH CONTENT --> <!-- Various types of lists can occur within the body of a paragraph, and generally where one can occur, so can any other type. --> <!ENTITY % list "(seqlist | randlist | deflist)"> <!-- Unnumbered paragraph content consists of text, with optionally intermixed lists, applicability definitions (and math displays, if the math package is included). --> <!-- NOTE: regarding the adaptation of this document type declaration set for use with other document classes. Per the rules of FIPS PUB 152, regarding the timing of the resolution of parameter entities, the content of the following parameter entity cannot be used directly within a content model that occurs before the referenced are resolved, due to the parameter entity references within it. --> <!ENTITY % paracon "(%text; | %list; | applicdef %mathcon;)+"> <!-- (UNNUMBERED) PARAGRAPHS AND PARAGRAPH-LIKE ELEMENTS --> <!-- Special paragraphs usually are just an appropriately labelled paragraph, but in certain cases they can have more than one paragraph within them. --> <!ENTITY % spcpara "(warning | caution | note)"> <!-- NUMBERED/TITLED "PARAGRAPHS" AND OTHER SUBSECTION-LIKE ELEMENTS --> <!-- Step content consists of optional warnings, cautions, and notes (in that order, and applying to the following paragraphs), and then an unnumbered paragraph, followed optionally by notes. Numbered paragraph content consists of a title, the same special and unnumbered paragraphs followed optionally by notes as are in step content, and finally optional steps. --> <!ENTITY % stepcon "(specpara | para)+"> <!-- NOTE: regarding the adaptation of this document type declaration set for use with other document classes. Per the rules of FIPS PUB 152, regarding the timing of the resolution of parameter entities, the content of the following parameter entity cannot be used directly within a content model that occurs before the referenced are resolved, due to the parameter entity references within it. --> <!ENTITY % titles "(title %shortitle;)"> <!-- NOTE: regarding the adaptation of this document type declaration set for use with other document classes. Per the rules of FIPS PUB 152, regarding the timing of the resolution of parameter entities, the content of the following parameter entity cannot be used directly within a content model that occurs before the referenced are resolved, due to the parameter entity references within it. --> <!ENTITY % nparcon "(%titles;, (specpara | para)+)"> <!-- FRONT, BODY, REAR MATTER ELEMENTS --> <!-- The content models for <front>, <idinfo>, <section>, and <rear> are entities so that they can be redefined. --> <!ENTITY % frnt " ((idinfo | warnsum | chgsheet | lep | promul chgrec | foreword | | preface | intro | contents | illuslist | tablelist | safesum | | howtouse )+) "> <!ENTITY % idinf " ((pubno | prepubno | nsn | chgnum | revnum | titleblk | mfr | contractno | docmfr | seal | notice | downgrd | pubdate | chgdate)+) "> <!-- %chgsht is a parameter entity reference for the content model of the element type chgsheet. It is used as is or it may be changed for use with a specific class of documents. An example of how it may be changed would be if the system were to generate the change sheet. Then the content model would be changed to a declared content of EMPTY. --> <!ENTITY % chgsht "(chgnum, address, date, prtitle, para?, chglist)"> <!-- NOTE: regarding the adaptation of this document type declaration set for use with other document classes. Per the rules of FIPS PUB 152, regarding the timing of the resolution of parameter entities, the content of the following parameter entity cannot be used directly within a content model that occurs before the referenced are resolved, due to the parameter entity references within it. --> <!ENTITY % sect "(%titles;, para0*)"> <!ENTITY % rr "((appendix | glossary | index | errpt | foldsect)+)"> <!-- MISCELLANEOUS --> <!-- SPECIAL CHARACTER SETS --> <!-- The following public character entity sets are required to meet the general requirements of most service applications. Exceptional character requirements may be met by selecting additional public character entity sets from Appendix C. Those exceptional requirements must be separately specified in the contract. --> <!ENTITY % ISOlat1 PUBLIC "ISO 8879:1986//ENTITIES Added Latin 1//EN"> <!ENTITY % ISOpub PUBLIC "ISO 8879:1986//ENTITIES Publishing//EN"> <!ENTITY % ISOgrk3 PUBLIC "ISO 8879:1986//ENTITIES Greek Symbols//EN"> <!ENTITY % ISOnum PUBLIC "ISO 8879:1986//ENTITIES Numeric and Special Graphic//EN" > <!ENTITY % ISOtech PUBLIC "ISO 8879:1986//ENTITIES General Technical//EN" > %ISOlat1; %ISOpub; %ISOgrk3; %ISOnum; %ISOtech; <!-- ELEMENT DEFINITIONS --> <!-- BIG ELEMENTS (BIGGER THAN FRONT MATTER, BODY, OR REAR MATTER) --> <!-- A document contains volumes, a volume contains parts, a part has front matter, body, and rear matter. --> <!ELEMENT doc - - (%doc;) +(%docexpt;)> <!ATTLIST doc %docatt; %secur; > <!ELEMENT volume - - ((docpart, docpart+) | rear?)> <!ATTLIST volume tocentry %yesorno; "1" %bodyatt; %secur;> <!ELEMENT docpart - - (front?, body?,rear?)> <!ATTLIST docpart %bodyatt; %secur; > <!-- FRONT MATTER AND ELEMENTS PECULIAR THERETO --> <!-- Front matter contains identifying information for the document: title and cover pages, foreword, various lists, and various special-purpose types of information interspersed. The %frnt; entity permits specialization to a particular variant DOCTYPE. --> <!-- entity % frnt " (idinfo | warnsum | chgsheet | lep | promul | chgrec | foreword | preface | intro | contents | illuslist | tablelist | safesum | howtouse )+ " --> <!ELEMENT front - - (%frnt;)> <!ATTLIST front %secur;> <!-- entity % idinf " (pubno | prepubno | nsn | chgnum | revnum | titleblk | mfr | contractno | docmfr | seal | notice | downgrd | pubdate | chgdate)+ " --> <!ELEMENT idinfo - - (%idinf;)> <!ATTLIST idinfo %secur;> <!ELEMENT (pubno | prepubno) - o (user?, docno)+> <!ATTLIST (pubno | prepubno) %secur;> <!ELEMENT user - - (%text;)> <!ATTLIST user %secur;> <!ELEMENT titleblk - - (volnum?, docpartn?, revnum?, doctype, maintlvl*, prtitle, stitle?)> <!ATTLIST titleblk %secur;> <!ELEMENT (volnum | docpartn | revnum | doctype | maintlvl | chgnum) - o (%text;)> <!ATTLIST (volnum | docpartn | revnum | doctype | maintlvl | chgnum) %secur;> <!ELEMENT prtitle - - (nomen, eqpttype?, (pslist | partno | serno | modelno | nsn)*, subject?)> <!ATTLIST prtitle %secur;> <!ELEMENT nomen - - (%text;)> <!ATTLIST nomen %secur;> <!ELEMENT eqpttype - - (%text;)> <!ATTLIST eqpttype %secur;> <!ELEMENT pslist - - (partno, serno)+> <!ATTLIST pslist %secur;> <!-- partno, serno, modelno, nsn found in %nums under "TEXT". --> <!ELEMENT subject - - (%text;)> <!ATTLIST subject %secur;> <!-- end <prtitle>, continue <titleblk> --> <!ELEMENT stitle - o (%text;)> <!ATTLIST stitle %secur;> <!-- end <titleblk>, continue <idinfo> --> <!ELEMENT (mfr | contractno | docmfr) - o (%text;)> <!ATTLIST (mfr | contractno | docmfr) %secur;> <!ELEMENT seal - o (graphic)> <!-- A <notice> usually contains standard text as defined in entity declarations in Appendix C, e.g.: <notice notctype="dist">&distrib;</notice>. If a notice containing other text is needed, the text should be directly included as the content of the <notice> element, e.g.: <notice notctype="auth">Published by Authority of the Secretary of Defense</notice>. --> <!ELEMENT notice - o (para+) +(table)> <!ATTLIST notice notctype (%notctype;) #IMPLIED %secur; > <!ELEMENT downgrd - o (authrty | phrase | oadr | date)+> <!ATTLIST downgrd %secur;> <!ELEMENT authrty - o (%text;)> <!ATTLIST authrty %secur;> <!ELEMENT (phrase | oadr) - o (%text;)> <!ATTLIST (phrase | oadr) %secur;> <!-- end <downgrd>, continue <idinfo> --> <!ELEMENT (pubdate | chgdate) - o (%text;)> <!ATTLIST (pubdate | chgdate) %secur;> <!-- end <idinfo>, continue <front> --> <!ELEMENT lep - o EMPTY> <!ELEMENT warnsum - o (para0 | para | warning)+> <!ATTLIST warnsum inschlvl NUTOKENS #IMPLIED delchlvl NUTOKENS #IMPLIED tocentry %yesorno "0" %secur; > <!ELEMENT chgsheet - o (%chgsht;)> <!ATTLIST chgsheet %secur;> <!ELEMENT chglist - o (removepg, insertpg)+> <!ATTLIST chglist %secur;> <!ELEMENT (removepg | insertpg) - o (#PCDATA)> <!ATTLIST (removepg | insertpg) %secur;> <!ELEMENT promul - - (title?, para*,(sigblk | graphic)*)> <!ATTLIST promul %bodyatt; %secur; > <!ELEMENT chgrec - o (table | graphic)> <!ATTLIST chgrec %bodyatt; %secur;> <!ELEMENT (foreword| preface | intro) - o (para0 | para | symbsect | abbrsect | %spcpara; | internatlstd | sigblk)+ +(figure | table | chart) > <!ATTLIST (foreword| preface | intro) tocentry %yesorno; "1" %bodyatt; %secur;> <!ELEMENT (symbsect| abbrsect) - o (deflist)+> <!ATTLIST (symbsect| abbrsect) %bodyatt; %secur; > <!ELEMENT internatlstd - o (para+)> <!ATTLIST internatlstd %secur;> <!ELEMENT sigblk - o (purpose | graphic | signer | position | organiz | address | date)+> <!ATTLIST sigblk sigtype (%sigtype;) #IMPLIED %secur; > <!ELEMENT purpose - o (%text;)> <!ATTLIST purpose %secur;> <!ELEMENT signer - o (%text;)> <!ATTLIST signer %secur;> <!ELEMENT (position| organiz | address) - o (%text;)> <!ATTLIST (position| organiz | address) %secur;> <!-- end <sigblk> and <foreword>, continue <front> --> <!ELEMENT howtouse - o ( %sect; | para0 | para+)> <!ATTLIST howtouse tocentry %yesorno; '0' shortentry %yesorno; '0' %bodyatt; %secur; > <!ELEMENT contents - o EMPTY> <!ATTLIST contents shortentry %yesorno; '0' > <!ELEMENT (illuslist| tablelist) - o EMPTY> <!ATTLIST (illuslist| tablelist) tocentry %yesorno; '1' shortentry %yesorno; '0' > <!ELEMENT safesum - o (para | precaut | warning | caution)+> <!ATTLIST safesum tocentry %yesorno; '0' shortentry %yesorno; '0' %bodyatt; %secur; > <!ELEMENT precaut - o (%text;)> <!ATTLIST precaut %secur;> <!-- BODY AND ELEMENTS PECULIAR THERETO --> <!-- The body contains two or more chapters, a chapter contains two or more sections, a section contains numbered paragraphs. If there is only one, its content may be used as the content of the next higher level, except that a one-chapter body cannot have sections. --> <!ELEMENT body - - (chapter | section | ftnsec | para0 | ddunit)+> <!ATTLIST body %secur;> <!ELEMENT chapter - - (%titles;,((section | ftnsec)+ | para0+))> <!ATTLIST chapter tocentry %yesorno; '1' shortentrY %yesorno; '0' %bodyatt; %secur; > <!--ENTITY % sect "(%titles;, para0+)"> --> <!ELEMENT (section|ftnsec) - - (%sect;)> <!ATTLIST (section| ftnsec) tocentry %yesorno; '1' shortentry %yesorno; '0' %bodyatt; %secur; > <!ELEMENT ddunit - - (ddintro, ddsheet+)> <!ATTLIST ddunit portion (section | chapter) #IMPLIED %secur; > <!ELEMENT ddintro - o (title | dddesc | ddindex)+> <!ATTLIST ddintro %secur;> <!ELEMENT dddesc - o ((para+, para0*) | para0+)> <!ATTLIST dddesc %secur;> <!ELEMENT ddindex - o (((para+, para0*)| para0+)|ddlist)> <!ATTLIST ddindex %secur;> <!ELEMENT ddlist - o (partno | pgno)+> <!ATTLIST ddlist %secur;> <!ELEMENT pgno - - (%text;)> <!ATTLIST pgno %secur;> <!ELEMENT ddsheet - - (partname, (partno | modelno | serno | eqpttype), ((para+, para0*)| para0+))> <!ATTLIST ddsheet %secur;> <!ELEMENT partname - - (%text;)> <!ATTLIST partname %secur;> <!-- REAR MATTER AND ELEMENTS PECULIAR THERETO --> <!-- entity % rr "(appendix | glossary | index | errpt | foldsect)+" --> <!ELEMENT rear - - (%rr;)> <!ATTLIST rear %secur;> <!ELEMENT appendix - - (%titles;,((section | ftnsec)+ | para0+))> <!ATTLIST appendix tocentry %yesorno; '1' shortentry %yesorno; '0' %bodyatt; %secur;> <!ELEMENT glossary - - (para?, (title,deflist)+)> <!ATTLIST glossary tocentry %yesorno; '1' shortentry %yesorno; '0' %secur;> <!ELEMENT index - o EMPTY> <!ATTLIST index shortentry %yesorno; '0'> <!ELEMENT errpt - o EMPTY> <!ATTLIST errpt erptype (%erptype;) #REQUIRED %secur;> <!ELEMENT foldsect - - (foldout+)> <!ATTLIST foldsect %secur;> <!ELEMENT foldout - o (figure | table | chart)> <!ATTLIST foldout pgstyle NUMBER #IMPLIED %secur;> <!--NUMBERED/TITLED PARAGRAPHS AND OTHER SUBSECTION-LIKE ELEMENTS--> <!--<!ENTITY % nparcon "(%titles;, (specpara | para)+, (step1, step1+)?)" --> <!ELEMENT specpara - - (warning*,caution*,note*,para,note*)> <!ATTLIST specpara %secur;> <!ELEMENT para0 - o (%nparcon;,step1*,subpara1*) +(figure | chart | table)> <!ATTLIST para0 tocentry %yesorno; '1' shortentry %yesorno; '0' %bodyatt; %secur;> <!ELEMENT subpara1 - o (%nparcon;,(step1+ | step2+)?, subpara2*)> <!ATTLIST (subpara1 | subpara2 | subpara3 | subpara4 | subpara5 | subpara6 | subpara7 | subpara8) tocentry %yesorno; '0' shortentry %yesorno; '0' %bodyatt; %secur;> <!ELEMENT subpara2 - o (%nparcon;,(step1+ | step3+)?, subpara3*)> <!-- See above for attribute list. --> <!ELEMENT subpara3 - o (%nparcon;,(step1+ | step4+)?, subpara4*)> <!-- See above for attribute list. --> <!ELEMENT subpara4 - o (%nparcon;,(step1+ | step5+)?, subpara5*)> <!-- See above for attribute list. --> <!ELEMENT subpara5 - o (%nparcon;,(step1+ | step6+)?, subpara6*)> <!-- See above for attribute list. --> <!ELEMENT subpara6 - o (%nparcon;,(step1+ | step7+)?, subpara7*)> <!-- See above for attribute list. --> <!ELEMENT subpara7 - o (%nparcon;,(step1+ | step8+)?, subpara8*)> <!-- See above for attribute list. --> <!ELEMENT subpara8 - o (%nparcon;,step1* )> <!-- See above for attribute list. --> <!-- ENTITY % stepcon "(specpara | para)+" --> <!ELEMENT step1 - o (%stepcon;,step2*)> <!ATTLIST (step1 | step2 | step3 | step4 | step5 | step6 | step7 | step8) %bodyatt; %secur;> <!ELEMENT step2 - o (%stepcon;,step3*)> <!-- See above for attribute list. --> <!ELEMENT step3 - o (%stepcon;,step4*)> <!-- See above for attribute list. --> <!ELEMENT step4 - o (%stepcon;,step5*)> <!-- See above for attribute list. --> <!ELEMENT step5 - o (%stepcon;,step6*)> <!-- See above for attribute list. --> <!ELEMENT step6 - o (%stepcon;,step7*)> <!-- See above for attribute list. --> <!ELEMENT step7 - o (%stepcon;,step8*)> <!-- See above for attribute list. --> <!ELEMENT step8 - o (%stepcon;)> <!-- See above for attribute list. --> <!-- (UNNUMBERED) PARAGRAPHS AND PARAGRAPH-LIKE ELEMENTS --> <!-- (Unnumbered) paragraphs contain running text, possibly interrupted by lists, applicability definitions, and (if mathpack is included) displayed formulae. Occasionally, a paragraph may consist solely of a list, definition, or formula without any running text. --> <!-- entity % paracon "((%text; | %list; | applicdef %mathcon;)+)" --> <!ELEMENT para - o (%paracon;)> <!ATTLIST para %bodyatt; %secur; > <!-- Various types of lists can occur within the body of a paragraph, and generally where one can occur, so can any other type. --> <!-- entity % list "(seqlist | randlist | deflist)" --> <!ELEMENT (seqlist | randlist) - - (title?, item+)> <!ATTLIST seqlist prefix CDATA #IMPLIED numstyle (arabic | romanuc | romanlc | alphauc | alphalc) #IMPLIED %bodyatt; %secur;> <!ATTLIST randlist prefix CDATA #IMPLIED %secur; > <!ELEMENT item - o (para+) +(table)> <!ATTLIST item id ID #IMPLIED label CDATA #IMPLIED %secur; > <!ELEMENT deflist - - (title?, (term, def)+)> <!ATTLIST deflist %secur;> <!ELEMENT term - o (%text;)> <!ATTLIST term %secur;> <!ELEMENT def - o (para+) +(table)> <!ATTLIST def %secur;> <!ELEMENT applicdef - - (title?, applichd, applicid+)> <!ATTLIST applicdef id ID #REQUIRED %secur;> <!ELEMENT applichd - o (term, def)> <!ATTLIST applichd %secur;> <!ELEMENT applicid - o (term, def)> <!ATTLIST applicid id ID #REQUIRED %secur;> <!-- SPECIAL PARAGRAPH ELEMENTS --> <!--entity % spcpara "(warning | caution | note)" --> <!ELEMENT (warning | caution | note) - - (graphic | para | %list;)+ -(figure | table | chart)> <!ATTLIST warning type CDATA #IMPLIED xrefid IDREF #IMPLIED vital %yesorno; '0' %secur;> <!ATTLIST (caution | note) type CDATA #IMPLIED xrefid IDREF #IMPLIED %secur;> <!-- RUNNING TEXT --> <!-- Various numbers embedded in running text are tagged to permit easy identification for database work. They generally have no special display formatting requirements. --> <!ELEMENT xref - o EMPTY> <!ATTLIST xref xrefid IDREF #REQUIRED xidtype (text | figure |table) #REQUIRED pretext CDATA #IMPLIED posttext CDATA #IMPLIED %secur;> <!ELEMENT extref - o EMPTY> <!ATTLIST extref docno CDATA #IMPLIED pretext CDATA #IMPLIED posttext CDATA #IMPLIED %secur;> <!ELEMENT graphic - o EMPTY> <!ATTLIST graphic boardno ENTITY #REQUIRED graphsty NMTOKEN #IMPLIED llcordra CDATA #IMPLIED rucordra CDATA #IMPLIED reprowid NUTOKEN #IMPLIED reprodep NUTOKEN #IMPLIED hscale NUTOKEN #IMPLIED vscale NUTOKEN #IMPLIED scalefit %yesorno; #IMPLIED hplace (left | right | center | none) #IMPLIED vplace (top | middle | bottom | non) #IMPLIED coordst CDATA #IMPLIED coordend CDATA #IMPLIED rotation NUMBER #IMPLIED %secur;> <!ELEMENT symbol - o EMPTY> <!ATTLIST symbol boardno ENTITY #REQUIRED reprowid NUTOKEN #IMPLIED reprodep NUTOKEN #IMPLIED hscale NUTOKEN #IMPLIED vscale NUTOKEN #IMPLIED scalefit %yesorno; #IMPLIED offset NUTOKEN #IMPLIED rotation NUMBER #IMPLIED %secur;> <!ELEMENT (subscrpt | supscrpt) - - RCDATA> <!ATTLIST (subscrpt | supscrpt) %secur;> <!ELEMENT (tool | testeq | material | torqueval) - - (%text;)> <!ATTLIST (tool | testeq | material | torqueval) %content; %secur;> <!ELEMENT dataiden - - (%text;)> <!ATTLIST dataiden %bodyatt; %secur;> <!ELEMENT ftnref - o EMPTY> <!ATTLIST ftnref xrefid IDREF #REQUIRED> <!ELEMENT indxflag - o EMPTY> <!ATTLIST indxflag ref1 CDATA #IMPLIED ref2 CDATA #IMPLIED ref3 CDATA #IMPLIED ref4 CDATA #IMPLIED %secur;> <!ELEMENT verbatim - - CDATA> <!ATTLIST verbatim allowbrk %yesorno; '1' %secur;> <!ELEMENT emergency - - (%text;)> <!ELEMENT change - - (%text;)> <!ATTLIST change level NUMBER #IMPLIED change (add | delete) #IMPLIED mark %yesorno; #IMPLIED %secur;> <!ELEMENT emphasis - - (%text;)> <!ATTLIST emphasis emph NAMES #REQUIRED> <!ELEMENT applicabil - - (%text;)> <!ATTLIST applicabil applicrefid IDREFS #REQUIRED applictype IDREFS #IMPLIED %secur;> <!-- Various numbers embedded in running text are tagged to permit easy identification for database work. They generally have no special display formatting requirements. --> <!-- entity % nums "(partno | serno | modelno | nsn | partdesc | smrcode | sssn | refdes | lin | docno | faultcode | figindex)" --> <!ELEMENT (partno | serno | modelno | nsn | partdesc | smrcode | sssn | refdes | lin | docno) - - (%text;)> <!ATTLIST (partno | serno | modelno | nsn | partdesc | smrcode | sssn | refdes | lin | docno) %secur;> <!ELEMENT faultcode - - (%text;)> <!ATTLIST faultcode %content; %secur;> <!ELEMENT figindex - o (xref, callout)> <!ATTLIST figindex %secur;> <!ELEMENT callout - - (%text;)> <!ATTLIST callout assocfig IDREF #IMPLIED> <!-- MISCELLANEOUS ELEMENTS --> <!-- <pgbrk>, <brk>, <arbtext>, and <hrule>, are similar to various elements in %text;, but are permitted more universally. <date> and <title> are special purpose but oft- used elements that occur in numerous content models. --> <!ELEMENT pgbrk - o EMPTY> <!ATTLIST pgbrk pgnumber CDATA #IMPLIED chglevel NUMBER #IMPLIED> <!ELEMENT brk - o EMPTY> <!ATTLIST brk type (col | line | epg | opg | npg)'line'> <!ELEMENT arbtext - - RCDATA> <!ATTLIST arbtext arbtype NUMBER #IMPLIED> <!ELEMENT hrule - o EMPTY> <!ATTLIST hrule thick NUTOKEN #REQUIRED offset NUTOKEN #REQUIRED length NMTOKEN #REQUIRED> <!ELEMENT date - o (%text;)> <!ATTLIST date %secur;> <!ELEMENT (title | shorttitle) - o (%text;) -(table | chart | figure)> <!ATTLIST (title | shorttitle) %secur;> <!-- FLOATING ELEMENTS --> <!-- Floating elements are only loosely attached to a particular point in the text. They are printed/displayed somewhere nearby their "attachment point"; just where is prescribed by the FOSI. <figure>s, <table>s, and <chart>s have their "attachment point" at the point where they occur in the text. The location of the body of a <ftnote> is independent of its "attachment point"; each <ftnote> is identified by an ID value, and the "attachment point" is the (first occurring) <ftnref> that references that ID. --> <!ELEMENT figure - - ((%titles;)?,(tgroup+ | graphic+))> <!ATTLIST figure tocentry %yesorno; '1' shortentry %yesorno; '0' orient (port | land) 'port' %bodyatt; %secur;> <!ELEMENT subfig - - ((graphic | macrograph) & table? & legend?)> <!ELEMENT macrograph - - (graphic+)> <!ATTLIST macrograph reprowid NUTOKEN #IMPLIED reprodep NUTOKEN #IMPLIED graphstyleid NMTOKEN #IMPLIED> <!ELEMENT legend - o (callout, def)+> <!ATTLIST legend assocfig IDREF #IMPLIED %secur;> <!ELEMENT (table | chart) - - ((%titles;,tgroup+) | graphic+) -(table | chart | figure)> <!ATTLIST (table | chart) tabstyle NMTOKEN #IMPLIED tocentry %yesorno; '1' shortentry %yesorno; #IMPLIED frame (top | bottom | topbot | all | sides | none) #IMPLIED colsep %yesorno; #IMPLIED rowsep %yesorno; #IMPLIED orient (port | land) #IMPLIED pgwide %yesorno; #IMPLIED %bodyatt; %secur;> <!ELEMENT tgroup - o (colspec*,spanspec*,thead?, tfoot?, tbody)> <!ATTLIST tgroup cols NUMBER #REQUIRED tgroupstyle NMTOKEN #IMPLIED colsep %yesorno; #IMPLIED rowsep %yesorno; #IMPLIED align (left | right | center | justify | char) 'left' charoff NUTOKEN '50' char CDATA '' %secur;> <!ELEMENT colspec - o EMPTY> <!ATTLIST colspec colnum NUMBER #IMPLIED colname NMTOKEN #IMPLIED align (left | right | center | justify | char ) #IMPLIED charoff NUTOKEN #IMPLIED char CDATA #IMPLIED colwidth CDATA #IMPLIED colsep %yesorno; #IMPLIED rowsep %yesorno; #IMPLIED> <!ELEMENT spanspec - o EMPTY> <!ATTLIST spanspec namest NMTOKEN #REQUIRED nameend NMTOKEN #REQUIRED spanname NMTOKEN #REQUIRED align (left | right | center | justify | char ) 'center' charoff NUTOKEN #IMPLIED char CDATA #IMPLIED colsep %yesorno; #IMPLIED rowsep %yesorno; #IMPLIED> <!ELEMENT (thead | tfoot) - o (colspec*, row+) -(entrytbl)> <!ATTLIST thead valign (top | middle | bottom) 'bottom' %secur;> <!ATTLIST tfoot valign (top | middle | bottom) 'top' %secur;> <!ELEMENT tbody - o (row+)> <!ATTLIST tbody valign (top | middle | bottom) 'top' %secur;> <!ELEMENT row - o (entry | entrytbl)+> <!ATTLIST row rowsep %yesorno; #IMPLIED valign (top | bottom | middle) #IMPLIED %secur;> <!ELEMENT entry - o ((para | warning | caution | note | legend)| %paracon;)+> <!ATTLIST entry colname NMTOKEN #IMPLIED namest NMTOKEN #IMPLIED nameend NMTOKEN #IMPLIED spanname NMTOKEN #IMPLIED morerows NUMBER '0' colsep %yesorno; #IMPLIED rowsep %yesorno; #IMPLIED rotate %yesorno; '0' valign (top | bottom | middle) #IMPLIED align (left | right | center | justify | char ) #IMPLIED charoff NUTOKEN #IMPLIED char CDATA #IMPLIED %secur;> <!ELEMENT entrytbl - - (colspec*, spanspec*, thead?, tbody)+ -(entrytbl)> <!ATTLIST entrytbl cols NUMBER #REQUIRED namest NMTOKEN #IMPLIED nameend NMTOKEN #IMPLIED tgroupstyle NMTOKEN #IMPLIED colname NMTOKEN #IMPLIED spanname NMTOKEN #IMPLIED colsep %yesorno; #IMPLIED rowsep %yesorno; #IMPLIED align (left | right | center | justify | char ) #IMPLIED charoff NUTOKEN #IMPLIED char CDATA #IMPLIED %secur;> <!ELEMENT ftnote - - (para+) -(ftnote | ftnref) +(table)> <!ATTLIST ftnote id ID #REQUIRED mark (ctr | sym) 'ctr' label CDATA #IMPLIED %secur;> <!-- ELEMENT TYPES WHOSE USE IS NOT ILLUSTRATED IN THIS DECLARATION SET --> <!ELEMENT contassurpg - o EMPTY> <!ATTLIST contassurpg content ENTITY #REQUIRED> <!ELEMENT refdoc - o (docno+)> <!ELEMENT cfgpge - o EMPTY> <!ATTLIST cfgpge name ENTITY #REQUIRED> <!ELEMENT coverindex - o EMPTY> <!ELEMENT staloc - o EMPTY> <!ATTLIST staloc name ENTITY #REQUIRED> <!ELEMENT testcode - o (%text;)> <!ATTLIST testcode codetype (major | minor | sec) 'major' %content;> 60. ALPHABETICAL LISTING OF TAG DESCRIPTIONS 60.1 Text types. The list of text types and their associated numbers have not yet been determined. The list will specify the legal values for the "texttype" attribute cited in the Body Attribute Set. They may be listed here, as in previous publications, or listed externally. 60.2 Element and attribute set descriptions. Table I provideS an alphabetically sorted, semantic description of each element type used in the sample DTD. Element types are to be used with their respective attribute definitions. Semantic descriptions of each element type are provided so that users may choose the most appropriate element type when creating a document type declaration for their application. Content models of element types may vary from document type declaration to document type declaration. 60.2.1 Mathematical Element Type Descriptions. Descriptions of the element types used within the &mathpac; PUBLIC entity are reproduced with the permission of the International Organization for Standardization (ISO), from ISO/IEC/TR 9573:1988 Information processing - SGML support facilities - Techniques for using SGML. 60.2.2 Table Components. There are three columns in the table. Each is described below. 60.2.2.1 Element Type/Attribute Column. The first column gives the name of the element type and a listing of each of its attributes (or attribute sets). No values are given for the attributes in this column. Attribute sets are not resolved. 60.2.2.2 Full-Name Column. The second column is the natural language name of the element type. 60.2.2.3 Description Column. The third column provides several descriptions. First, there is a description of the element type itself. Then each attribute is listed, divided into groupings of required or optional. If the declared value of an attribute can be a list of tokens, they are provided; otherwise the keyword is given. The default value of the attribute is also given. If the default value is #IMPLIED, it signifies that the application may imply the value if it is not explicitly provided in the element type's usage. If a null value is to be assumed when a value is not specified for an attribute with an IMPLIED default, then "(NULL)" will follow the word "IMPLIED." Otherwise the implication shall be explained. 60.3 Attribute Set Descriptions. There are also attribute set descriptions provided in this table, alphabetically with the element types. These attribute sets are not element types themselves, but rather are incorporated by reference with element types. These attribute sets are detailed in Table II. TABLE I. Element and attribute set descriptions. Element/Attribute Full Name Description <abbrsect Abbreviation Section Identifies an abbreviation section. Optional Attribute(s) %bodyatt; %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <address Address Identifies address information. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <appendix Appendix Identifies an appendix of the document. Optional Attribute(s) tocentry =x TOCENTRY: If the value consists only of zeros, the element's number and title are not used in the contents. Any other numeric value triggers the Appendix title's use in the contents listing. Declared Value = %yesorno;(NUMBER) Default = "1" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno;(NUMBER) Default = "0" TABLE I. Element and attribute set descriptions - Continued. Element/Attribute Full Name Description %bodyatt; %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur; > %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <applicabil Applicability Identifies the scope of information with a specific applicability. Applicability typically refers to the configuration of the equipment. However, it can also be used to refer to any other classification of applicability, such as skill level. When less than a complete element such as a paragraph has an applicability that differs from the rest of the same element, then <applicability> is used to delimit the scope of the peculiar applicability information. If the entire element has the same applicability, then the applicability attributes from the Body Attribute Set (%bodyatt;) are used. applicrefid=x Required Attribute(s) APPLICREFID: References unique identifier(s) assigned to applicability identifier(s) (<applicid id='xxx'>). An example might be a particular aircraft tail number(s). Declared Value = IDREFS applictype =x Optional Attribute(s) APPLICTYPE: References the unique applicability definition (<applicdef id='xxx'>). An example might be that the type of applicability would be aircraft tail numbers. This attribute is optional as it may be derived depending on the context in which the element is used. Declared Value = IDREFS Default = IMPLIED (NULL) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <applicdef Applicability Definition Defines the various applicability codes that may be associated with the content of the document and their meaning. Similar in nature to a definition list. Required Attribute(s) id =x ID: Unique identifier for the type of applicability. Examples would include aircraft tail numbers, aircraft model numbers, user skill track categories. Declared Value = ID %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each element in the set. <applichd Applicability Definition Heading Each applicability is known by a unique identifier which in turn refers to a coupling of a term and a definition. Various classes of terms may be used relevant to applicability. This heading classifies the type of applicability being defined. Optional Attribute(s) %secur; = x> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each element in the set. <applicid Applicability Identifier Each applicability identifier, typically referring to a coupling of a term and a definition, is known by a unique identifier. It is with this element type that a symbol or term is associated with its definition. Examples of applicability identifiers might be particular aircraft tail numbers. Required Attribute(s) id =x ID: The unique identifier of the applicability identifier. Declared Value = ID Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each element in the set. <arbtext Arbitrary Text Identifies arbitrary information determined by the corresponding definition in the Output Specification. This text is typically used for manually putting in text to be used as headers or footers. It does not imply any particular processing by default. Rather this information is determined by the usages outlined in the Formatting Output Specification Instance. arbtype =x> Optional Attribute(s) ARBTYPE: Identifies different types of arbitrary text defined in Appendix B. A number that corresponds to a definition in Appendix B (i.e., header or footer information). Declared Value = NUMBER Default = IMPLIED (NULL) <authrty Classification Authority Identifies the classification authority for a downgrade. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <body Body Matter Identifies the body of the document. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <brk User Created Break User-created break to handle column, line, even/odd, and next page breaks. This element type is used to indicate that a break should be forced at its occurrence during processing of the information. There is no implication that there are any other breaks within the document, and, therefore, no implication that this type of break supports page integrity. type =x> Optional Attribute(s) TYPE: Type of break to be used. Declared Value = col (break to new column on same or next page), line (break line), epg (break to next even page), opg (break to next odd page), or npg (break to next page). Default = "line" <callout Callout Identifies a graphic callout identifier in text that correlates to a graphic callout in a figure used within the document. Optional Attribute(s) assocfig=x> ASSOCFIG: Reference to the unique identifier of the figure with which the callout is associated. Declared Value = IDREF Default = IMPLIED (NULL) <caution Caution Identifies a caution. Optional Attribute(s) type =x TYPE: This specifies the type of caution. This type may be used as the title of the caution. Declared Value = CDATA Default = IMPLIED (NULL) xrefid =x XREFID: This specifies a cross reference to the unique identifier of a corresponding element. Declared Value = IDREF Default = IMPLIED (NULL) %secure;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <cfgpe Configuration Page Defines an external configuration page. The location of the external entity is defined with the value of the content attribute. This will be an NDATA external entity in a content data notation defined within the appropriate document type declaration. The external entity is assumed to be a full- page graphic. Required Attribute(s) name =x> NAME: Value is the name of an external entity. Declared Value = ENTITY <change Change Information Indicates the scope of changed information. Optional Attribute(s) level =x LEVEL: Identifies level of change. Declared Value = NUMBER Default = IMPLIED (NULL) change =x CHANGE: Type of change Declared Value = add or delete. Default = IMPLIED (NULL) mark =x MARK: If the value consists only of zeros, no sidemark is used; if the value is any other numeral, a sidemark is used. If left to default, a sidemark is used only if the value of the level attribute is equal to the value of the change level of the document. Declared Value = %yesorno;(NUMBER) Default = IMPLIED (NULL) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <chapter Chapter Identifies a chapter of the document. tocentry =x> Optional Attribute(s) TOCENTRY: If the value consists only of zeros, the element's number and title are not used in the contents. Any other numeric value triggers the Chapter title's use in the contents listing. Declared Value = %yesorno;(NUMBER) Default = "1" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno;(NUMBER) Default = "0" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <chart Chart Identifies a chart, typically tabular information that contributes to the List of Illustrations. Optional Attribute(s) tabstyle =x TABSTYLE: A unique chart style defined in the FOSI. Declared Value = NMTOKEN Default = IMPLIED (NULL) tocentry =x TOCENTRY: If other than zeros, and the title is present, this chart title should be included in the list of illustrations. (Ignore if the optional title is omitted). Declared Value = %yesorno;(NUMBER) Default = "1" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno;(NUMBER) Default = IMPLIED (NULL) frame =x FRAME: Describes position of outer rulings. Declared Value = sides (left and right), top (below title), bottom (after last row possibly of tfoot material), topbot (both top and bottom), all (all of above), or none (none of above). Default = IMPLIED (NULL implies value from tabstyle in FOSI, if available, NULL if not) colsep =x COLSEP: Default for all items in this chart. If other than zeros, display the internal column rulings to the right of each item; if only zeros, do not display it. Ignored for the last column, where the frame sides setting applies. Declared Values = %yesorno;(NUMBER) Default = IMPLIED (NULL implies value from tabstyle in FOSI, if available, NULL if not) rowsep =x ROWSEP: Default for all items in this chart. If other than zeros, display the internal vertical row ruling below each item. If only zeros, do not display it. Ignored for the last row of the chart. Declared Value = %yesorno;(NUMBER) Default = IMPLIED (NULL implies value from tabstyle in FOSI, if available, NULL if not) orient =x ORIENT: Orientation of the entire table. Declared Value = port (table writing direction, along rows, is the same as marginal text), or land (table writing direction is 90 degrees counterclockwise to marginal text). Default = IMPLIED (NULL implies value from tabstyle in FOSI, if available, NULL if not) pgwide =x PGWIDE: If other than zeros, the chart runs across the page. If only zeros, the chart runs across just the (galley) width of the current column of the page (regardless of orient). If the value is only zeros, it has no meaning for orient=land. Declared Value = %yesorno;(NUMBER) Default = IMPLIED (NULL implies value from tabstyle in FOSI, if available, NULL if not) %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <chgdate Change Date Identifies the document's publication change date. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <chglist Change List The change list is associated with the change sheet. It lists which pages are to be removed and which are to be inserted relative to the current change. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <chgnum Change Number Identifies the current change level of the document. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <chgrec Change Record Identifies the change record information. Optional Attribute(s) %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <chgsheet Change Sheet Identifies a change sheet in the document. This sheet may be made up of elements explicitly placed in the document or it may be generated by the system. The purpose of the change sheet is to list the reason for the change to the data and also to provide a table designating which pages are to be removed and which are to be inserted. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <col Matrix Column Identifies a column of a matrix. Optional Attribute(s) align =x> ALIGN: Horizontal alignment of the characters within a matrix as defined in the "f.align" entity. Declared Value = center, left, or right. Default = "center" <colspec Column Specification Specifies a column, a vertical portion of a <table>, <chart>, or <entrytbl>. The default values come from the <tgroup>, <thead>, or <tfoot> starting the current (enclosing) group. Each <colspec> is for a single column, so it properly has a column number, colnum, implicitly in order starting from 1, and an optional colname by which it is known when used in any <spanspec> or in <entry>. A <colspec> set on <thead> or <tfoot> should be complete for all columns. It overrides those on the containing <tgroup> and applies to just the <thead> or <tfoot>. If there is no <colspec> used within <thead> or <tfoot>, then the <colspec> of the containing <tgroup> (or the prior <tgroup>) is used. <Colspec>s from the containing <tgroup> apply to <tbody>. colnum =x Optional Attribute(s) COLNUM: Number of column, counting from 1 at left of the chart or table. Declared Value = NUMBER Default = IMPLIED (NULL) colname =x COLNAME: Name of column, used to specify the position in a row, or the start or end of a horizontal span of columns (<spanspec>). Declared Value = NMTOKEN Default = IMPLIED (NULL) align =x ALIGN: Text horizontal position within the column. Declared Value = left (quad flush left), center (centered), right (quad flush right), justify (both quad left and quad right), or char (align on leftmost of char, positioned by charoff). Default = IMPLIED Note: If no value given, obtain from FOSI. charoff =x CHAROFF: For align="char", horizontal character offset is the percent of the current column width to the left of the (left edge of the) alignment character. Declared Value = NUTOKEN Default = IMPLIED, from enclosing table group char =x CHAR: If align = "char", the value is the single alignment character on which the first to occur of this character in the entry is aligned. Entries not containing this character are aligned to the left of this position. Declared Value = CDATA Default = IMPLIED, from enclosing table group colwidth =x COLWIDTH: Either proportional measure of the form number*, i.e., "5*" for 5 times the proportion , or "*" (="1*"); fixed measure, i.e., 2pt for 2 point, 3pc for 3 pica; or mixed measure, i.e., 2*+3pt. Coefficients are positive numbers with up to2 decimal places. Declared Value = CDATA Default = IMPLIED Note: If no value is given, then obtain value >from the FOSI or, if there is no FOSI value, then assume a proportion of 1. colsep =x COLSEP: Default for all items in this column (within the closing group) of the table or chart. If other than zeros, display the internal column ruling to the right of each item; if only zeros, do not display it. Ignored for the last column, where the frame setting applies. Declared Value = %yesorno;(NUMBER) Default = IMPLIED, from enclosing table group. rowsep =x> ROWSEP: Default for all items in this column (within the enclosing group) of the table or chart. If other than zeros, display the internal horizontal row ruling below each item. If only zeros, do not display it. Ignored for the last row of the table, since overridden by the frame setting. Declared Value = %yesorno;(NUMBER) Default = IMPLIED, from enclosing table group. <contassurpg Content Assurance Page Defines an external content assurance page. The location of the external entity is defined with the value of the content attribute. Required Attribute(s) content =x> CONTENT: The name of the entity that defines the content assurance page should be the value of this attribute. Declared Value = ENTITY <contents Generated Table of Contents Identifies element that refers to a table of contents generated by the receiving system. Optional Attribute(s) shortentry =x> SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno;(NUMBER) Default = "0" <contractno Contract Number Identifies a contract number. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <coverindex> Generated Cover Index Identifies the element that refers to a front-cover index generated by the receiving system. This index is typically in a table of contents order and uses the <shorttitle> content, if present (<title>, if not). It usually appears on the cover of documents conforming to MIL- M-63036 and MIL-M-63038. Not all instances of element types that support the "shortentry" attribute need be extracted for any one publication. <dataiden Data Identification Number Identifies information that has a different "texttype" from that of the surrounding text within a sentence, paragraph, step, note, table entry, etc. Optional Attribute(s) %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <date Date Identifies a date of the form yy/mm/dd. However, it may be formatted for presentation as appropriate to the application. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <dddesc Difference Data Description Identifies a difference data description. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <ddindex Difference Data Index Identifies the difference data index. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <ddintro Difference Data Introduction Identifies the difference data introduction. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <ddlist Difference Data List Identifies a difference data list. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <ddsheet Difference Data Sheet Identifies a difference data sheet. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <ddunit Difference Data Unit Identifies a difference data unit. Optional Attribute(s) portion =x PORTION: Specifies to what major document structure the difference data pertains. Declared Value = section or chapter. Default = IMPLIED (NULL implies "chapter" if <section> is not used in instance) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <def Definition Identifies a definition. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <deflist Definition List Identifies a definition list. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <df Display Formula Identifies a display formula. Optional Attribute(s) id =x ID: Unique identifier of the display formula. Declared Value = ID Default = IMPLIED (NULL) align =x ALIGN: Horizontal alignment of the display formula as declared in the "f.align" entity. Declared Value = center, left, or right. Default = "left" num =x> NUM: Specifies an explicit formula number; if omitted, sequential numbering of the formulae would normally be performed by the text formatter. Declared Value = CDATA Default = IMPLIED (NULL) <dfg Display Formula Group Identifies a formula group whose content is display formulae. Optional Attribute(s) id =x ID: Unique identifier of the display formula. Declared Value = ID Default = IMPLIED (NULL) align =x ALIGN: Horizontal alignment of the display formula as declared in the "f.align" entity. Declared Value = center, left, or right. Default = "left" num =x> NUM: Specifies an explicit formula group number; if omitted, sequential numbering of the formulae would normally be performed by the text formatter. Declared Value = CDATA Default = IMPLIED (NULL) <dfref Formula Reference Identifies a reference to a formula or formula group. refid =x> Required Attribute(s) REFID: Reference to the unique identifier of a <df>. Declared Value = IDREF Optional Attribute(s) page =x PAGE: Page number is added (default) to the reference of the unique identifier of a <df>. Declared Value = yes or no. Default = "yes" <doc Document Level Element Identifies the start of the data of a technical document. Required Attribute(s) service =x SERVICE: Specifies the military servoce of the procuring activity (service primarily responsible for the document). Declared Value = af (Air Force), navy (Navy), army (Army), mc (Marine Corps), dla (Defense Logistics Agency), cg (Coast Guard), or %service; (contractor defined). Optional Attribute(s) docid =x DOCID: Unique identifier of the document, which can be used to perform interdocument cross references. However, it should be noted that this is a particular of the application and is not an SGML construct that is validated by the parser. Declared Value = CDATA Default = IMPLIED (NULL) docstat =x DOCSTAT: Specifies the current status of the document publication. Declared Value = revision (newly revised), change (newly changed), draft (draft), prelim (preliminary title), or formal (formal version). Default = "formal" mantype =x> MANTYPE: Designates the manual type of the document. Declared Value = standard (standard manual), card, or decal. NOTE: a card type manual is normally a set of 5" x 7" index cards used within the Air Force for purposes such as periodic inspections (pre/post flight inspections). "card" and "decal" are for use with documents conforming to MIL-M- 63004. Default = "standard" <docmfr Document Manufacturer Identifies the manufacturer of the document. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <docno Document Number Identifies a document number. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <docpart Document Part Identifies a part in technical manuals, all of which have the same publication number. Optional Attribute(s) %bodyatt;= x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <docpartn Document Part Number Identifies the document part number. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <doctype Document Type Identifies the type of publication. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <downgrd Downgrade Notice Identifies the downgrade notice. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <emergency> Emergency Information Indicates the scope of emergency information. <emphasis Emphasis Indicates the scope of emphasized information. The emphasis types available will be listed in the Output Specification (Apd. B) and associated with a named value. Required Attribute(s) emph =x> EMPH: Names identifying the types of emphasis. More than one name can be used, meaning that each of the names will produce a form of emphasis. Emphasis types are identified in the Output Specification and Formatting Output Specification Instance for the document. Declared Value = NAMES <entry Entry Identifies an entry in a table or chart. Default values come from the table or chart, tgroup, colspec, spanspec, thead, tfoot, tbody, or row attlist values for like-named attributes. An entry not specified by a spanspec gets its defaults from its starting column. colname =x Optional Attribute(s) COLNAME: Column name of entry. Omit if spanname is present. Declared Value = NMTOKEN Default = IMPLIED (NULL, implies the next column after the end of the prior entry or entrytbl, else the first column of the row). namest =x NAMEST: Name of leftmost column of span. Names are identified in colspec of the current tgroup. Declared value = NMTOKEN nameend=x NAMEEND: Name of rightmost column of span. Names are identified in colspec of the current tgroup. Declared value = NMTOKEN spanname =x SPANNAME: Name of a horizontal span. Declared Value = NMTOKEN Default = IMPLIED (NULL) morerows =x MOREROWS: Number of additional rows in a vertical straddle. Declared Value = NUMBER Default = "0" colsep =x COLSEP: If other than zeros, display the internal vertical column ruling at the right of the entry; if only zeros, do not display it. Ignored for the last column, where the frame setting applies. Declared Value = %yesorno;(NUMBER) Default = IMPLIED, from colspec or spanspec rowsep =x ROWSEP: If other than zeros, display the internal horizontal row rulings below the entry; if only zeros, do not display it. Ignored for the last row where the frame setting applies. Declared Value = %yesorno;(NUMBER) Default = IMPLIED, from the row. rotate =x ROTATE: Rotations are not additive to those specified in FOSI. Content is either in the orientation of the table (value is one or more zeros) or 90 degrees counterclockwise to table orientation (value is other than zeros). Declared Value = %yesorno;(NUMBER) Default = "0" valign =x VALIGN: Text vertical positioning within the entries. Declared Value = top, middle (vertically centered), or bottom. Default = IMPLIED align =x ALIGN: Text horizontal position within the column. Declared Value = left (quad flush left), center (centered), right (quad flush right), justify (both quad left and right), or char (align on leftmost of char position by charoff). Default = IMPLIED, from colspec or spanspec. char =x CHAR: If align ="char", the value is the single alignment character on which the first to occur of this character in the entry is aligned. If that character does not occur in the entry, the entry aligns to the right of that character offset. Declared Value = CDATA Default = IMPLIED (NULL implies there is no aligning character). charoff =x CHAROFF: For align ="char", percent of the current width to the left of the (left edge of) the character. Declared Value = NUTOKEN Default = IMPLIED, from colspec or spanspec. %secur> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <entrytbl Entry Table An entrytbl takes the place of an entry, but fits into a single row. It permits subdivisions of an entry or horizontal span of entries into possibly different columns and (sub)rows. Note that several entrytbls may occur in the same body row, and these could have a different number of (sub)rows. There is no implication of alignment of (sub)rows in different entrytbls. Default values come from the table or chart, tgroup, colspec, spanspec thead, tfoot, tbody, or row attlist values for like-named attributes, in the same manner as an entry. cols =x Required Attribute(s) COLS: Number of columns in the table or chart. Declared Value = NUMBER tgroupstyle =x Optional Attribute(s) TGROUPSTYLE: A unique table group style defined in the FOSI. Declared Value = NMTOKEN Default = IMPLIED (NULL) colname =x COLNAME: Leftmost column of entrytbl in the row of the table or chart. Declared Value = NMTOKEN Default = IMPLIED (NULL implies next column). spanname =x SPANNAME: Name of a horizontal span. Declared Value = NMTOKEN Default = IMPLIED (NULL) namest =x NAMEST: Name of leftmost column of span. Names are identified in colspec of the current tgroup. Declared value = NMTOKEN nameend=x NAMEEND: Name of rightmost column of span. Names are identified in colspec of the current tgroup. Declared value = NMTOKEN colsep=x COLSEP: If other than zeros, display the internal vertical column ruling at the right of the entrytbl, (but not for the last table column, where the siderule setting applies). If only zeros, do not display. Declared Value = %yesorno;(NUMBER) Default = IMPLIED, from enclosing table group. rowsep =x ROWSEP: If other than zeros, display by default the horizontal rulings below entrytbl (but not for entries in the last row of the table or chart). If only zeros, do not display ruling. Declared Value = %yesorno;(NUMBER) Default = IMPLIED, from enclosing table group. align=x ALIGN: Text horizontal position within the column. Declared Value = left (quad flush left), center (centered), right (quad flush right), justify (both quad left and right), or char (align on leftmost of char position by charoff). Default = IMPLIED, from colspec or spanspec. charoff =x CHAR: If align ="char", the value is the single alignment character on which the first to occur of this character in the entry is aligned. If that character does not occur in the entry, the entry aligns to the right of that character offset. Declared Value = CDATA Default = IMPLIED (NULL implies there is no aligning character). char=x CHAROFF: For align ="char", percent of the current width to the left of the (left edge of) the character. Declared Value = NUTOKEN %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <eqpttype Equipment Type Identifies the equipment type associated with the document. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <errpt Error Report System-generated form for reporting errors in the document. Required Attribute(s) erptype =x ERPTYPE: Type of error report form to be used. Declared Value = tmdr (Navy technical manuals deficiency report), afto22 (Air Force report), or da2028 (Army report). Optionally, other report types may be defined in the replacement text of %erptype;. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <extref Cross Reference This is a cross reference to another document. Optional Attribute(s) docno =x DOCNO: Value is the identifier of an external document. Declared Value = CDATA Default = IMPLIED (NULL) pretext =x PRETEXT: Text that will precede the cross reference when resolved for display. Declared Value = CDATA Default = IMPLIED (NULL) posttext =x POSTTEXT: Text that will follow the cross reference when resolved for display. Declared Value = CDATA Default = IMPLIED (NULL) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <faultcode Fault Code Identifies a fault code. Optional Attribute(s) %content; =x %CONTENT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <figindex Figure Index Number Identifies a figure index number. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <figure Figure Identifies a figure in the document. Optional Attribute(s) tocentry =x TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "1" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" orient =x ORIENT: Specifies the orientation of the figure on the page, together with its title. (Note: Rotations are additive.) Declared Value = port or land. Default = "port" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <foldout Foldout Identifies a foldout within the foldout section. It can consist of a table, figure, or chart. Optional Attribute(s) pgstyle =x PGSTYLE: Refers to page style defined in the corresponding FOSI. Declared Value = NUMBER Default = IMPLIED (NULL) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <foldsect Foldout Section Identifies the foldout section of the document. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <foreword Foreword Identifies the foreword material of the document. The foreword, when included in a volume or part of a manual, shall contain the purpose and scope of the manual plus any other information required by the technical content specification. It may define new abbreviations and symbols. tocentry =x Optional Attribute(s) TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "1" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <front Front Matter Identifies the front matter. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <ftnote Footnote Identifies the body of a footnote in the document. Required Attribute(s) id =x ID: Unique identifier of the footnote. Declared Value = ID mark =x Optional Attribute(s) MARK: If symbol is chosen, they will be assigned in the order specified in the GPO Manual of Style. Declared Value = ctr (counter) or sym (symbol). Default = "ctr" label =x LABEL: If used, it specifies the number or symbol of the ftnote and overrides autogeneration of the number or symbol by the processing system. Declared Value = CDATA Default = IMPLIED (NULL) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <ftnref Footnote Reference Indicates a footnote reference. Required Attribute(s) xrefid =x> XREFID: Unique identifier of the footnote being referenced. Declared Value = IDREF <ftnsec Footnote Section Identifies a section that is used to list footnotes. tocentry =x Optional Attribute(s) TOCENTRY: If the value consists only of zeros, the element's number and title are not used in table of contents. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "1" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <glossary Glossary Identifies the glossary information of a document. Optional Attribute(s) tocentry =x TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "1" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <graphic Graphic Identifies a graphic. A graphic is stored either as vector (MIL-D-28000 or MIL-D-28003) or raster (MIL-R-28002) data and is used as an illustration in the document. Required Attribute(s) boardno =x BOARDNO: Enter unique graphic identifier. Declared Value = ENTITY Optional Attribute(s) graphsty =x GRAPHSTY: Characteristic provided to allow for cases where the "grphstyl" ID is to be used. Declared Value = NMTOKEN Default = IMPLIED (NULL implies only one style available). llcordra =x LLCORDRA: Left lower coordinate pair of the portion of the graphic to be placed in the portion of the repro area, separated by comma. Declared Value = CDATA Default = IMPLIED (NULL) rucordra =x RUCORDRA: Right upper coordinate pair of the portion of the graphic to be placed in the portion of the repro area, separated by comma. Declared Value = CDATA Default = IMPLIED (NULL) reprowid =x REPROWID: Repro area width. Declared Value = NUTOKEN Default = IMPLIED (NULL implies value from <macrograph>, if available, NULL if not) reprodep =x REPRODEP: Repro area depth. Declared Value = NUTOKEN Default = IMPLIED (NULL implies value from <macrograph>, if available, NULL if not) hscale =x HSCALE: Horizontal scaling. Declared Value = NUTOKEN Default = IMPLIED (NULL) vscale =x VSCALE: Vertical scaling. Declared Value = NUTOKEN Default = IMPLIED (NULL) scalefit = x SCALEFIT: Characteristic allows the graphic to be scaled as needed to fit the size of the reproduction area. Declared Value = %yesorno; (NUMBER) Default = IMPLIED (NULL) hplace =x HPLACE: Horizontal placement in the available repro area. Declared Value = left, right, center, or none (equivalent to a null value which defaults to implied by the graphstyle). Default = IMPLIED (NULL) vplace =x VPLACE: Vertical placement in the available repro area. Declared Value = top, middle, bottom, or non (equivalent to a null value which defaults to implied by the graphstyle). Default = IMPLIED (NULL) coordst =x COORDST: Left lower coordinate pair, separated by comma. Start position in repro area for placement of the portion of the graphic specified by llcordra and rucordra. Declared Value = CDATA Default = IMPLIED (NULL) coordend =x COORDEND: Right upper coordinate pair, separated by comma, end position in repro area for placement of portion of the graphic. Declared Value = CDATA Default = IMPLIED (NULL) rotation =x ROTATION: Degree of rotation of the graphic. Declared Value = NUMBER Default = IMPLIED (NULL) %bodyatt =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <howtouse How To Use Identifies "how to use" information. Optional Attribute(s) tocentry =x TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "0" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <hrule Horizontal Rule Ability to place a horizontal rule (line). Required Attribute(s) thick =x THICK: Rule Thickness Declared value = NUTOKEN offset =x OFFSET: Offset from the baseline. Declared value = NUTOKEN length =x> LENGTH: Rule Length Declared value = NMTOKEN <idinfo Identification Information Identifies information which will be used to produce the title page and cover. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <illuslist Generated List of Illustrations Identifies element that refers to a list of illustrations generated by the receiving system. Optional Attribute(s) tocentry =x TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "1" shortentry =x> SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" <index Index Identifies element that refers to an index generated by the receiving system. Optional Attribute(s) shortentry=x> SHORTENTRY: If the value consists only of zeros, the Index is not listed in the <coverindex> or any other type of compiled listing. Any other numeric value triggers its listing. Declared Value = %yesorno; (NUMBER) Default = "0" <indxflag Index Entry Flag Identifies text of an item to be extracted for the index. The four attributes, ref1-ref4, refer to the level of the index entry. If the item is a ref2 entry, then the ref1 attribute must be used. If the item is a ref3 entry, then both the ref1 and ref2 attributes must be used and so forth. Optional Attribute(s) ref1 =x REF1: First level reference on an index flag. Declared Value = CDATA Default = IMPLIED (NULL) ref2 =x REF2: Second level reference on an index flag. Declared Value = CDATA Default = IMPLIED (NULL) ref3 =x REF3: Third level reference on an index flag. Declared Value = CDATA Default = IMPLIED (NULL) ref4 =x REF4: Fourth level reference on an index flag. Declared Value = CDATA Default = IMPLIED (NULL) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <insertpg Insert Page Identifies the page number of a page to be inserted relative to the current change level. It is usually associated with a change list and change sheet. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <internatlstd International Standard Information Identifies information regarding compliance with international standards. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <intro Introduction Identifies the introductory material of the document. tocentry =x Optional Attribute(s) TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "1" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <item Item Identifies an item typically occurring within a type of list. Optional Attribute(s) id =x ID: Unique identifier of the item. Declared Value = ID Default = IMPLIED (NULL) label =x LABEL: If used, it specifies the number or symbol of the item and it will override the numbering that would be generated based on the type of the list. Declared Value = CDATA Default = IMPLIED (NULL) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <legend Legend Identifies a legend. Optional Attribute(s) assocfig =x ASSOCFIG: Reference to the unique identifier of the figure with which the legend is associated. Declared Value = IDREF Default = IMPLIED (NULL) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <lep> Generated List of Effective Pages Identifies element that refers to a list of effective pages generated by the receiving system. <lin Line Item Number Identifies a line item number. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <macrograph> Macrographic Identifies a group of graphics that are used together to form an illustration. All graphics in each macrograph share the same repro area. If reprowid and/or reprodep are specified on a graphic within the context of a macrograph, they are ignored. Optional Attribute(s) reprowid=x REPROWID: Width of the repro area. Declared Value = NUTOKEN Default = IMPLIED (NULL) reprodep=x> REPRODEP: Depth of the repro area. Declared Value = NUTOKEN Default = IMPLIED (NULL) <maintlvl Maintenance Level Identifies the maintenance level of the manual. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <material Material Identifies a material. %content; =x Optional Attribute(s) %CONTENT; Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <mfr Manufacturer Identifies the equipment manufacturer. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <modelno Equipment Model Number Identifies an equipment model number. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <nomen Equipment Nomenclature Identifies the equipment nomenclature of the document. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <note Note Identifies a note. Optional Attribute(s) type =x TYPE: This specifies the type of note. This type may be used as the title of the note. Declared Value = CDATA Default = IMPLIED (NULL) xrefid =x XREFID: This specifies a cross reference to the unique identifier of a corresponding element. Declared Value = IDREF Default = IMPLIED (NULL) <notice Notice Identifies a notice. notctype =x Optional Attribute(s) NOTCTYPE: Specifies the type of notice to be inserted on the page. Declared Value = dist (distribution), auth (authority), fouo (For Official Use Only), service (service), pgclass (This page is unclassified notice), disclos (disclosure), supersed (supersedure), effdate (effective date), suppl (supplement notice), nopg (number of notice pages in a secured document), noclaspg (number of classified pages in a secured document), warning (warning notice), destr (destruction), safesup (safety supplement), opersup (operational supplement), or maintsup (maintenance supplement). The paramenter entity %notctype may also be defined for the document to extend the possible choices. The text of notices is either explicitly present or implicitly present through the use of entity references. Default = IMPLIED (NULL) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <nsn National Stock Number Identifies a national stock number. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <oadr Official Authority Downgrade Review Identifies text instructing confirmation of downgrade notice with official authority. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <organiz Organization Identifies an agency, organization, or company. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <para Paragraph Text Identifies text within a paragraph. Optional Attribute(s) %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <para0 Primary Paragraph Identifies a primary numbered paragraph in the document's structure. tocentry =x Optional Attribute(s) TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "1" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <partdesc Part Description Identifies an equipment part description. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <partname Part Name Identifies an equipment part name. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <partno Equipment Part Number Identifies an equipment part number. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <pgbrk Page Break User- or system-inserted page break to preserve page integrity along with the capability to specify the change level of the delimited page. This element type is used to designate the limits of a page. Further, through attributes, it provides the ability to designate the folio and current change level of the delimited information. If this element type is used, it is assumed it will be used consistently throughout the document to designate all page breaks. Optional Attribute(s) pgnumber =x PGNUMBER: The page number of the information preceding the <pgbrk>. Declared Value = CDATA Default = IMPLIED, the next page in the document. chglevel =x> CHGLEVEL: The change level of the information preceding the <pgbrk>. Declared Value = NUMBER Default = IMPLIED (NULL) <pgno Page Number Identifies a page number. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <phrase Downgrade Phrase Identifies the downgrade notice text. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <position Position Identifies position or rank. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <precaut Precaution Identifies a precaution. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <preface Preface Identifies the preface material of the document. The preface, when included in a volume or part of a manual, shall contain the purpose and scope of the manual plus any other information required by the technical content specification. It may define new abbreviations and symbols. Optional Attribute(s) tocentry =x TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "1" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <prepubno Previous Publication Number Identifies the previous publication number of the document. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <promul Promulgation Information Identifies the promulgation information. %bodyatt; =x Optional Attribute(s) %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <prtitle Prime Title Identifies the prime title block of the document. A graphic may be used before, after, or within the nomenclature, type, or the subject. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <pslist Part Number / Serial Number List Identifies a list of equipment part and serial numbers. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <pubdate Publication Date Identifies the base publication date. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <pubno Publication Number Identifies the publication number of the document. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <purpose Signature Purpose Identifies the purpose of the signature (i.e., Validated By, Verified By, etc.) %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <randlist Random List Identifies a random list. Optional Attribute(s) prefix =x PREFIX: Identifies the prefix desired on items in the list such as a symbol (e.g., bullet). Declared Value = CDATA Default = IMPLIED (NULL) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <rear Rear Matter Identifies the rear matter. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <refdes Reference Designation Index Number Identifies the reference designation index number of an equipment part. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <refdoc> Referenced Documents Identifies the documents referenced by the manual. <removepg Remove Page Identifies the page number of the page to be removed relative to the current change level. It is usually associated with a change list and change sheet. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element Default = As appropriate for each attribute in the set. <revnum Revision Number Identifies revision number of the document. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element Default = As appropriate for each attribute in the set. <row Row of Table Group Identifies the row information in a tgroup of a table or chart. Default values come from the table or chart, tgroup, colspec, or spanspec attlist values for like-named attributes. Within an entrytbl, defaults are from that entrytbl. Optional Attribute(s) rowsep =x ROWSEP: Default for all items in this column (within the enclosing group) of the table or chart. If other than zeros, display the internal horizontal row ruling below each row. If only zeros, do not display it. Ignored for the last row of the table, where the frame specification determines the ruling. Declared Value = %yesorno; (NUMBER) Default = IMPLIED, from enclosing <tgroup>. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <safesum Safety Summary Identifies the safety summary information of the document. Optional Attribute(s) tocentry =x TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "1" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %service;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <seal> Seal Identifies the seal, if any, associated with the document. <section Section Identifies a section of a document. tocentry =x Optional Attribute(s) TOCENTRY: If the value consists only of zeros, the element's number and title are not used in table of contents. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "1" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <seqlist Sequential List Identifies a sequential list. It is composed of an optional title and one or more items. Optional Attribute(s) prefix =x PREFIX: The user may specify the prefix desired on the items in the list, such as "STEP." Declared Value = CDATA Default = IMPLIED (NULL) numstyle =x NUMSTYLE: Enumeration style to be used on items within the <seqlist>. Declared Value = arabic, romanuc (upper case roman), romanlc (lower case roman), alphauc (upper case alpha), or alphalc (lower case alpha). Default = IMPLIED (NULL implies compliance with GPO style). %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <serno Equipment Serial Number Identifies an equipment serial number. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <shorttitle Short Title Identifies text for a short title. Short titles may be used to capture a shortened form of a title. This shortened form may then be used in a variety of ways. Examples of how it may be used include extraction for use in compiled data and capture of text for use in a running header. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <sigblk Signature Block Identifies a signature block. Optional Attribute(s) sigtype =x SIGTYPE: Type of signature block as defined by the "%sigtype;" entity. Declared Value = preparer, approval, review, concur, or other. Default = IMPLIED %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <signer Signer Identifies the signer of a particular signature block. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <smrcode SMR Code Identifies the SMR code of an equipment part. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <spanspec Spanned Column Specification Identifies a horizontal span of columns and associated attributes that can subsequently be referenced by its spanname to provide attributes repeatedly used in the entries or entry tables in several rows of the table group controlled by the group <colsdef>, or within the specific <thead>, <tfoot>, or <tbody> context in which the <spanspec> occurs. Namest and nameend identify the first and last columns in increasing order that identify the span. The reason colname is used rather than colnum in identifying <spanspec> is that the names are independent of revisions that may change the number of inserted/deleted columns, as long as namest remains to the left of (has a smaller colnum than) nameend. <Spanspec>s set on <thead> or <tfoot> override those on the containing <tgroup> and apply to just the <thead> or <tfoot>. <Spanspec>s from the containing <tgroup> apply to <tbody>. Required Attribute(s) namest =x NAMEST: Name of leftmost column of span. Names are identified in colspec of the current tgroup. Declared value = NMTOKEN nameend =x NAMEEND: Name of rightmost column of span. Names are identified in colspec of the current tgroup. Declared value = NMTOKEN spanname =x SPANNAME: Name of the horizontal span. Declared value = NMTOKEN align =x Optional Attribute(s) ALIGN: Text horizontal position within the column. Declared Value = left (quad flush left), center (centered), right (quad flush right), justify (both quad left and quad right), or char (align on leftmost of char, positioned by charoff). Default = "center" charoff =x CHAROFF: For align="char", the percent of the width of the current span of columns to the left of the (left edge of) the alignment character. Declared Value = NUTOKEN Default = IMPLIED, from namest column's colspec. char =x CHAR: If align ="char", the value is the single alignment character on which the first to occur of this character in the entry is aligned. Entries not containing this character are aligned to the left of this position. Declared Value = CDATA Default = IMPLIED, from namest column's colspec. colsep =x COLSEP: Default for all items in this column (within the closing group) of the table or chart. If other than zeros, display the internal column ruling to the right of the entry; if only zeros, do not display it. This permits an override of the ruling that the nameend column already provides for ruling to the right. Ignored for the last column, where the siderule setting applies. Declared Value = %yesorno; (NUMBER) Default = IMPLIED, from namest column's colspec. rowsep =x> ROWSEP: Default for all items in this span of columns (within the enclosing group) of the table or chart. If other than zeros, display the internal horizontal row ruling below each entry. If only zeros, do not display it. Ignored for the last row of the table, where the frame specification determines the ruling. Declared Value = %yesorno; (NUMBER) Default = IMPLIED, from namest column's colspec. <specpara Special Content Paragraph Identifies a paragraph that may be used with special paragraph content, such as warnings, cautions, or notes. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <sssn SSSN Number Identifies system/subsystem/subject number (MIDAS) of an equipment part. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <staloc Station Locator Diagram Defines a station locator diagram using an external entity. name =x> Required Attribute(s) NAME: The value is the name of the external entity. Declared Value = ENTITY <step1 First Level Procedural Step Identifies a first level procedural step. Optional Attribute(s) %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <step2 Second Level Procedural Step Identifies a second level procedural step. Optional Attribute(s) %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <step3 Third Level Procedural Step Identifies a third level procedural step. %bodyatt; =x Optional Attribute(s) %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <step4 Fourth Level Procedural Step Identifies a fourth level procedural step. Optional Attribute(s) %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <step5 Fifth Level Procedural Step Identifies a fifth level procedural step. Optional Attribute(s) %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <step6 Sixth Level Procedural Step Identifies a sixth level procedural step. Optional Attribute(s) %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <step7 Seventh Level Procedural Step Identifies a seventh level procedural step. Optional Attribute(s) %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <step8 Eighth Level Procedural Step Identifies an eighth level procedural step. %bodyatt; =x Optional Attribute(s) %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <stitle Document Subtitle Identifies the subtitle of the document, typically serves as the volume title. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <subfig> Subfigures Each subfig is one or more graphics or macrographics and implies that all the data within the subfig remains together on one display surface, such as a page. The use of subfig makes it possible to have multiple sheet figures. Many graphics, across multiple pages are within the scope of one numbered and titled figure. <subject Document Subject Matter Identifies the document's subject matter. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <subpara1 First Level Subordinate Paragraph Identifies a first level subordinate paragraph. Optional Attribute(s) tocentry =x TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "0" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <subpara2 Second Level Subordinate Paragraph Identifies a second level subordinate paragraph. tocentry =x Optional Attribute(s) TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "0" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <subpara3 Third Level Subordinate Paragraph Identifies a third level subordinate paragraph. tocentry =x Optional Attribute(s) TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "0" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <subpara4 Fourth Level Subordinate Paragraph Identifies a fourth level subordinate paragraph. Optional Attribute(s) tocentry =x TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "0" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <subpara5 Fifth Level Subordinate Paragraph Identifies a fifth level subordinate paragraph. Optional Attribute(s) tocentry =x TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "0" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <subpara6 Sixth Level Subordinate Paragraph Identifies a sixth level subordinate paragraph. Optional Attribute(s) tocentry =x TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "0" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <subpara7 Seventh Level Subordinate Paragraph Identifies a seventh level subordinate paragraph. tocentry =x Optional Attribute(s) TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "0" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <subpara8 Eighth Level Subordinate Paragraph Identifies an eighth level subordinate paragraph. Optional Attribute(s) tocentry =x TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "0" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno; (NUMBER) Default = "0" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <subscrpt Subscript Indicates a subscript. For use external to mathematical formulae. Optional Attribute(s) %secur; = x> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <supscrpt Superscript Indicates a superscript. For use external to mathematical formulae. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <symbol Symbol Identifies a unique symbol not found in character sets, is used as a graphic in text. A symbol is stored as a graphic either as vector (MIL-D-28000 or MIL-D- 28003) or raster (MIL-R-28002) data and is used as a symbol in the text of a document. Required Attribute(s) boardno =x BOARDNO: Enter unique symbol identifier. Declared Value= ENTITY Optional Attribute(s) reprowid =x REPROWID: Repro area width. Declared Value = NUTOKEN Default = IMPLIED (NULL) reprodep =x REPRODEP: Repro area depth. Declared Value = NUTOKEN Default = IMPLIED (NULL implies value from <macrograph>, if available, NULL if not> hscale =x HSCALE: Horizontal scaling. Declared Value = NUTOKEN Default = IMPLIED (NULL) vscale =x VSCALE: Vertical scaling. Declared Value = NUTOKEN Default = IMPLIED (NULL) scalefit =x SCALEFIT: Characteristic allows the symbol to be scaled as needed to fit the size of the reproduction area. Declared Value=%yesorno; (NUMBER) Default = IMPLIED (NULL) offset =x OFFSET: Vertical relationship to type baseline of text. A positive value will move the symbol below the baseline and a negative value will place the symbol above the baseline. Units of measure are in points. Declared Value = NMTOKEN Default = IMPLIED (NULL) (Zero points offset) rotation =x ROTATION: Degree of rotation of the symbol. Declared Value = NUMBER Default= IMPLIED (NULL) %secur: =x> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default: As appropriate for each attribute in the set. <symbsect Symbol Section Identifies a symbol section. Optional Attribute(s) %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <table Table Identifies a table. Optional Attribute(s) tabstyle =x TABSTYLE: A unique table style defined in the FOSI. Declared Value = NMTOKEN Default = IMPLIED (NULL) tocentry =x TOCENTRY: If other than zeros, and the title is present, this table title should be included in the list of tables. (Ignore if the optional title is omitted). Declared Value = %yesorno;(NUMBER) Default = "1" shortentry =x SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno;(NUMBER) Default = IMPLIED (NULL) frame =x FRAME: Describes position of outer rulings. Declared Value = sides (left and right), top (below title), bottom (after last row possibly of tfoot material), topbot (both top and bottom), all (all of above), or none (none of above). Default = IMPLIED (NULL implies value from tabstyle in FOSI if available, NULL if not). colsep =x COLSEP: Default for all items in this table. If other than zeros, display the internal column rulings to the right of each item; if only zeros, do not display it. Ignored for the last column, where the frame setting applies. Declared Values = %yesorno;(NUMBER) Default = IMPLIED (NULL implies value from tabstyle in FOSI if available, NULL if not). rowsep =x ROWSEP: Default for all items in this table. If other than zeros, display the internal horizontal row ruling below each item. If only zeros, do not display it. Ignored for the last row of the table, where the frame value applies. Declared Value = %yesorno;(NUMBER) Default = IMPLIED (from tabstyle if used, NULL if not). orient =x ORIENT: Orientation of the entire chart. Declared Value = port (table writing direction, along rows, is the same as marginal text), or land (table writing direction is 90 degrees counterclockwise to marginal text). Default = IMPLIED (NULL implies value from tabstyle in FOSI if available, NULL if not). pgwide =x PGWIDE: If other than zeros, the table runs across the page. If only zeros, the table runs across just the (galley) width of the current column of the page (regardless of orient). If the value is only zeros, it has no meaning for orient=land. Declared Value = %yesorno; (NUMBER) Default = IMPLIED (NULL implies value from tabstyle in FOSI if available, NULL if not). %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. <tablelist Generated List of Tables Identifies element that refers to a list of tables generated by the receiving system. tocentry =x Optional Attribute(s) TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno;(NUMBER) Default = "1" shortentry =x> SHORTENTRY: If the value consists only of zeros, the element's <shorttitle> (or <title>, if no short title is given) is not used in the <coverindex> or any other type of compiled listing. Any other numeric value triggers the use of the shorttitle. Declared Value = %yesorno;(NUMBER) Default = "0" <tbody Table Body Identifies the body of the <table>. Optional Attribute(s) valign =x VALIGN: Text vertical positioning within the entries. Declared Value = top, middle (approximately vertically centered), or bottom. Default = "top" %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <term Term Identifies a term, symbol, or abbreviation. %secur; =x Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <testcode Test Code Identifies the testcode for a specific test point. Optional Attribute(s) codetype =x CODETYPE: Specifies type of testcode. Declared Value = major (major test point), minor (minor test point), or sec (secondary test point). Default = "major" %content;> %CONTENT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <testeq Test Equipment Identifies a piece of test equipment. Optional Attribute(s) %content; =x %CONTENT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <tfoot Table Foot Identifies the footer information in a <table> or <chart> displayed after the <tbody> and also at the bottom of any <tbody> rows before a physical break. Optional Attribute(s) valign =x VALIGN: Text vertical positioning within the entries. Declared Value = top, middle (approximately vertically centered), or bottom. Default = "top" %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <tgroup Table Group Each <tgroup effectively identifies a new portion of a <table> or <chart>. If a new <colspec> is provided, it replaces a previous one. If both <colspec> and <spanspec> are new, that <spanspec> should refer to columns in the most recent <colspec>. If only a new <spanspec> is provided, it should refer to columns defined by the (most immediately prior) <colspec>s in a <tgroup> of the <table> or <chart>. On the other hand, a new <colspec> to either a <thead> or <tfoot> replaces all prior column definitions. Required Attribute(s) c ols =x C OLS: Number of columns in the table or chart. D eclared Value = NUMBER t groupstyle =x Optional Attribute(s) TGROUPSTYLE: A unique table group style defined in the FOSI. Declared Value = NMTOKEN Default = IMPLIED (NULL) colsep =x COLSEP: Default for items in this table group. If other than zeros, display the internal column rulings to the right of each item; if only zeros, do not display it. Ignored for the last column, where the frame setting applies. Declared Value = %yesorno; (NUMBER) Default = IMPLIED, from tgroupstyle if used, NULL if not. rowsep =x ROWSEP: Default for items in this table group. If other than zeros, display the internal horizontal row ruling below each item. If only zeros, do not display it. Ignored for the last row of the table, where the frame value applies. Declared Value = %yesorno; (NUMBER) Default = IMPLIED, from tgroupstyle if used, NULL if not. align =x ALIGN: Text horizontal position within the column (or portion of it controlled by this colsdef). Declared Value = left (quad flush left), center (centered), right (quad flush right), justify (both quad left and right), or char (align on leftmost of char, position by charoff). Default = "left" (unless overridden by tgroupstyle) charoff =x CHAROFF: For align ="char", percent of the current width to the left of the (left edge of) character. Declared Value = NUTOKEN Default = "50" (unless overridden by tgroupstyle) char =x CHAR: If align ="char", the value is the single alignment character on which the first to occur of this character in the entry is aligned. If that character does not occur in the entry, the entry aligns to the right of that character offset. Declared Value = CDATA Default = "" (unless overridden by tgroupstyle) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <thead Table Head Identifies the heading information in a <table> or <chart>, displayed at the top of the <table> and again at the top of any continuation after a physical break between <rows> in <tbody>. valign =x Optional Attribute(s) VALIGN: Text vertical positioning within the entries. Declared Value = top, middle (approximately vertically centered), or bottom. Default = "bottom" %secur;> %SECUR:; Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <title Title Identifies text for a title. %secur;> Optional Attribute(s) %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <titleblk Title Block Matter Identifies title block material. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <tool Tool Identifies a tool. %content; =x Optional Attribute(s) %CONTENT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <torqueval Torque Value Identifies a torque value. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <user User Service Identifies the user service prefix such as in a publication number. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <verbatim Verbatim Text Used to indicate if the text is to be picked up and laid down as it is. Typically, it implies the usage of a monospace font and the designated point size. All record ends are retained. The use of tabs in verbatim text may cause unexpected results and should therefore be avoided. allowbrk=x Optional Attribute(s) ALLOWBRK: Specifies if the verbatim information can be broken over a page boundary. The values are numeric. A value consisting only of zeros specifics that a break is not allowed; any other number specifies that a break is allowed. Declared Value = %yesorno; (NUMBER) Default = "1" %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <volnum Volume Number Identifies the number of the volume. Optional Attribute(s) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <volume Volume Separates a volume of a technical manual. Each volume of a technical manual has its own subtitle, but retains the same publication number as the other volumes. tocentry =x Optional Attribute(s) TOCENTRY: A non-zero number causes the volume and its number to be included in the contents, illuslist, and tablelist for the volume, and to propagate to any document-wide ones as well. If the value contains only zeros, the volume is not included. Declared Value = %yesorno; (NUMBER) Default = "1" %bodyatt; =x %BODYATT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <warning Warning Identifies a warning. type =x Optional Attribute(s) TYPE: This specifies the type of warning. This type may be used as the title of the warning. Declared Value = CDATA Default = IMPLIED (NULL) xrefid =x XREFID: This specifies a cross reference to the unique identifier of a corresponding element. Declared Value = IDREF Default = IMPLIED (NULL) vital =x VITAL: If the warning is not vital, use a value consisting only of zeros. Any other digit will imply the warning is vital. Vital warnings are used in the WARNSUM. Declared Value = %yesorno;(NUMBER) Default = "0" %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. <warnsum Warning Summary Identifies the warning summary information of the document. The warning summary consists of warnings extracted from the text based on their "vital" status or warnings which apply to the document generally. Optional Attribute(s) inschlvl =x INSCHLVL: Specifies the change level(s) at which information was inserted. An audit trail can be maintained by listing multiple change levels separated by spaces. Declared Value = NUTOKENS Default = IMPLIED (NULL) delchlvl =x DELCHLVL: Specifies the change level(s) at which information was deleted. An audit trail can be maintained by listing multiple change levels separated by spaces. Declared Value = NUTOKENS Default = IMPLIED (NULL) tocentry =x TOCENTRY: If the value consists only of zeros, the element's number and title are not used in contents, illuslist, or tablelist. Any other numeric value triggers their use in the appropriate listing. Declared Value = %yesorno; (NUMBER) Default = "0" %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element Default = As appropriate for each attribute in the set. <xref Cross Reference Value is the "id" of the element being referenced. The element's "id" value is replaced with the automatically assigned enumeration at the time of output. Example: <step2> See figure <xref xrefid="abc">. At output, the processing system will insert the correct enumeration, such as: See figure 4-29. Required Attribute(s) xrefid =x XREFID: Value is that of a unique identifier for cross referencing of information. Declared Value = IDREF xidtype =x XIDTYPE: Value is that of a string for identifying the nature of the information being cross referenced. Declared Value = text, table, or figure. pretext =x Optional Attribute(s) PRETEXT: Text that will precede the cross reference when resolved for display. Declared Value = CDATA Default = IMPLIED (NULL) posttext -=x POSTTEXT: Text that will follow the cross reference when resolved for display. Declared Value = CDATA Default = IMPLIED (NULL) %secur;> %SECUR;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. 70. ALPHABETICAL LISTING OF ATTRIBUTE DESCRIPTIONS 70.1 Attribute Set Descriptions. The following table lists each of the attribute types in the baseline tag set. The purpose of this table is to provide an alphabetically sorted, semantic description of each attribute that may be used to build document type declarations conforming to this specification. 70.1.1 Attribute Type Column. The first column gives the name of the attribute. No values are given for the attributes in this column. Attribute sets are not resolved. 70.1.2 Full-Name Column. The second column is the natural language name of the attribute. 70.1.3 Description Column. The third column provides attribute set descriptions which are listed alphabetically. TABLE II. Attribute set descriptions. Attribute Full Name Description %bodyatt; Body Attribute Set These attributes may be used with any element type that references this attribute set (%bodyatt;) in the document type declaration. Optional Attribute(s) id =x ID: An identifier of the element which is assigned at origination and which remains unchanged as the document is revised or updated even though the automatically assigned enumeration or manually-assigned "labels" change (in some cases many times). The value of the "id" is used when making references to the element from other portions of the document. If no ID is given, none will be maintained and the element can then not be cross-referenced to by means of an IDREF on another element or with <xref>. Declared Value = ID Default = IMPLIED (NULL) inschlvl =x INSCHLVL: Specifies the change level(s) at which information was inserted. An audit trail can be maintained by listing multiple change levels separated by spaces. Declared Value = NUTOKENS Default = IMPLIED (NULL) delchlvl =x DELCHLVL: Specifies the change level(s) at which information was deleted. An audit trail can be maintained by listing multiple change levels separated by spaces. Declared Value = NUTOKENS Default = IMPLIED (NULL) TABLE II. Attribute set descriptions - Continued. Attribute Full Name Description label =x LABEL: Label associated with paragraph, figure, or table (i.e., chapter number). Label is only appropriate for manually enumerated documents. Typically, the rendering system will autoenumerate the elements requiring it, in which case the label attribute is omitted. Declared Value = CDATA Default = IMPLIED (NULL) hcp =x HCP: Hardness Critical Process - If the value consists only of zeros, there is no hardness critical information. If another value is given, the element contains hardness critical information. Declared Value = %yesorno; (NUMBER) Default = "0" stub =x STUB: Partial document #CONREF attribute Declared Value (STUB) if present the content mode for this element is EMPTY. If absent, that content model is as indicated. Used in the transmittal master for partial documents to provide placeholders for missing or unchanged GIs Declared Value = STUB Default = #CONREF %content; %CONTENT;: Any of the attributes in the associated Attribute Set may be used with this element. Default = As appropriate for each attribute in the set. %content; Content Attribute Set These attributes may be used with any element type that references this attribute set (%content;) or the body attribute set (%bodyatt;) in the document type declaration. Optional Attribute(s) texttype =x TEXTTYPE: (pending information from OSD) Declared Value = NUMBER Default = IMPLIED (NULL) applictype =x APPLICTYPE: This attribute references unique identifier(s) assigned to applicability definition(s) (<applicdef id='xxx'>). An example might be that the type of applicability would be aircraft tail numbers. Although it is possible to derive the applicability type >from the applicability reference identifier, it may be explicitly stated with this attribute. Declared Value = IDREFS Default = IMPLIED (NULL) applicrefid =x APPLICREFID: References unique identifier(s) assigned to applicability identifier(s) (<applicid id='xxx'>). An example might be a particular aircraft tail number(s). Declared Value = IDREFS Default = IMPLIED (NULL) skilltrk =x SKILLTRK: Designation of the skill level of the user at which the current element of information is aimed. A particular set of values common to all documents has not been created. Currently, the relevant values are set by contract. Declared Value = NMTOKENS Default = IMPLIED (NULL) contype =x CONTYPE: Identifies the content type. When used with steps, the implied value is procedural. When used with all other element types, the implied value is descriptive. Declared Value = desc (Descriptive) or proc (procedural block format). Default = IMPLIED assocfig =x ASSOCFIG: Identifies associated figure(s) with the text data through the use of the "id" attribute in the <figure> tag. Declared Value = IDREFS Default = IMPLIED (NULL) assoctab =x ASSOCTAB: Identifies associated table(s) with the text data. Declared Value = IDREFS Default = IMPLIED (NULL) %f.style; Style Defines a mathematical style to be used with a formula. Optional Attribute(s) STYLE: Style of rules declared in the "f.style" entity. Declared Value = single, double, triple, dash, dots, or bold. %f.align; Mathematical Formula Alignment Defines the mathematical alignment position within a formula. Optional Attribute(s) ALIGN: Defines the values declared in the "f.align" entity. Declared Value = center, left, or right. %f.diff; Differential Differential tag that identifies a derivative. Optional Attribute(s) TYPE: Type of differential as declared in the "f.diff" entity. Declared Value = ordinary or partial %f.type; Type of Fence Identifies the character that will be used as a fence (e.g., open bracket). Optional Attribute(s) TYPE: Identifies the character to be used for the fence. Declared Value = paren, bracket, angbrack, brace, bar, or none. %f.func; Mathematical Function Identifies a mathematical function and its argument. By convention, most characters except numeral digits and syntax elements are set in italics in mathematical formulae. Exceptions to this convention include names of functions. Optional Attribute(s) TYPE: Defines the type of mathematical function whose values are declared in the "f.func" entity. Declared Value = and, antilog, arc, arccos, arcsin, arctan, arg, colog, cos, cosh, cot, coth, csc, ctn, deg, det, dim, exp, for, gcd, glb, hom, if, im, ker, lg, lim, ln, log, lub, max, min, mod, re, sec, sin, sinh, tan, or tanh. %f.ov; "Over" Embellishments Identifies parts of a formula over which special accents or diacritical marks are to be placed. (Over-Character Tag) Optional Attribute(s) TYPE: Defines the type of mark whose values are declared in the "f.ov" entity. Declared Value = dot, dotdot, dot3, dot4, tie, tiebrace, hat, haczeck, acute, grave, cedil, ring, macron, ogonek, dblac, breve, tilde, vec, rvec, dyad, or bar. %f.oper; Operator Identifies an operator within a formula. Defined by the values declared in the "f.oper" entity. Valid operators are: = mark, markref, break, sup, sub, sum, integral, product, plex, frac, diff, sqrt, root, square, power, pile, matrix, middle, tensor, mfn, box, fence, or vec. %f.pos; Position of Elements Identifies position of elements within a formula containing superscripts and subscripts. Optional Attribute(s) TYPE: Defines the position of elements whose values are declared in the "f.pos" entity. Declared Value = pre, mid, or post. %f.text; Type of Text Identifies the type of text to be used. Defines the type of text whose values are declared in the "f.text" entity. Valid values are: = #PCDATA, roman, italic, or ov. %itemid; Item Identifier Attribute Set These attributes may be used with any element type that references this attribute set (%itemid;) or the body attribute set (%bodyatt;) in the document type declaration. Optional Attribute(s) sssn =x SSSN: The value of this attribute would be the appropriate system/subsystem/subject number (sometimes referred to as a MIDAS number) of the equipment/part described in the text of the element type. Declared Value = CDATA Default = IMPLIED (NULL) unit =x unit: The value of this attribute would be the appropriate unit number of the equipment/part described in the text of the element type. Declared Value = CDATA Default = IMPLIED (NULL) module =x MODULE: The value of this attribute would be the appropriate module number of the equipment/part described in the text of the element type. Declared Value = CDATA Default = IMPLIED (NULL) lru =x LRU: The value of this attribute would be the appropriate line replaceable unit number of the equipment/part described in the text of the element type. Declared Value = CDATA Default = IMPLIED (NULL) assem =x ASSEM: The value of this attribute would be the appropriate assembly name of the equipment/part described in the text of the element type. Declared Value = CDATA Default = IMPLIED (NULL) subassem =x SUBASSEM: The value of this attribute would be the appropriate subassembly name of the equipment/part described in the text of the element type. Declared Value = CDATA Default = IMPLIED (NULL) ssubassm =x SSUBASSM: The value of this attribute would be the appropriate sub-subassembly name of the equipment/part described in the text of the element type. Declared Value = CDATA Default = IMPLIED (NULL) compon =x COMPON: The value of this attribute would be the appropriate component name of the equipment/part described in the text of the element type. Declared Value = CDATA Default = IMPLIED (NULL) partno =x PARTNO: The value of this attribute would be the appropriate part number of the equipment/part described in the text of the element type. Declared Value = CDATA Default = IMPLIED (NULL) refdes =x REFDES: The value of this attribute would be the appropriate reference designator of the equipment/part described in the text of the element type. Declared Value = CDATA Default = IMPLIED (NULL) %secur; Security Attribute Set These attributes may be used with any element type that references this attribute set (%secur;) in the document type declaration. security =x Optional Attribute(s) SECURITY: Security classification of the element. Declared Value = u (unclassified), c (confidential), s (secret), ts (top secret) Default = IMPLIED (NULL) restrict =x RESTRICT: Restrictions - These might include: noforeign, nato, nocontract, proprietary, fouo, etc. Declared Value = NMTOKENS Default = IMPLIED (NULL) release =x RELEASE: Release Specification - Countries to which document may be released. Declared Value = NMTOKENS Default = IMPLIED (NULL) codeword =x CODEWORD: Associated code words Declared Value = NMTOKENS Default = IMPLIED (NULL) scilevel =x SCILEVEL: Flag to indicate if element has a Special Compartmentalized Information level. Declared Value = %yesorno; (NUMBER) Default = "0" diglyph =x DIGLYPH: One or more two-letter codes defining the classification of the element. Values are determined by contract. Declared Value = NMTOKENS Default = IMPLIED (NULL) %yesorno; Yes or No Attribute Set The value of this attribute is a number. If only zeros are used, the response is "no." If any other numeric value is used, the response is "yes." OUTPUT SPECIFICATION 10. INTRODUCTION 10.1 Scope. This appendix describes a method for interchanging formatting requirements for military technical documents whose source files are tagged according to Document Type Definitions (DTD) developed in accordance with MIL-M-28001. Adherence to the rules described in this appendix allows for divergent receiving processing systems to unambiguously interpret the style and formatting intent of the sending system, such that by combining the tagged source file with the appropriate Formatting Output Specification Instance (FOSI), the resulting publication will preserve the information content of the original with similar presentation. This appendix is a mandatory part of the specification. The information contained herein is intended for compliance. The following functionality is not provided for in this version of the Output Specification (OS): a. Formatting mathematical elements. b. Using fragments of FOSIs to be merged with the baseline FOSIs. c. Supporting all functions necessary for producing change packages. d. Supporting all possible security classification markings. 10.2 Statement of purpose, premises. This specification is designed for use with all military specifications for technical documents. The military functional specification, such as MIL-M-38784, determines the actual requirements. A specific DTD interprets the content and structural requirements of a particular functional specification, and a specific FOSI interprets the style and formatting requirements of the functional specification. The designer of the DTD and FOSI is responsible for assuring that they convey a consistent, non-ambiguous, and complete description of the pertinent areas of logical tagging and output presentation from the military specification. It is a requirement of MIL-M-28001 that FOSIs be rigorous. If a particular contract calls for an exception, or variant interpretation of a functional specification, then an unambiguous FOSI must be created. This appendix describes the rules for creating all FOSIs to be included in or delivered in accordance with MIL-M-28001, as well as the interchange format to be used. Throughout this document the terms "Output Specification" and "OS" refer to this appendix, and the terms "Formatting Output Specification Instance" and "FOSI" refer to a particular application of the rules and methods set forth in this appendix to a military functional specification, such as MIL-M-38784. 10.2.1 Media. The media is the physical form on which information will be output, such as paper or electronic display screen. This version of MIL-M-28001, although mainly concerned with paper media, does allow some limited electronic presentation capabilities. Future versions of this specification will deal with electronic display. Throughout this appendix, the term "page" can be interpreted as a page of paper, an electronic screen, or the area inside the frame of a window on an electronic display. 10.2.2 Design goals. The overall goal of this specification is to allow for the interchange of style and formatting information of technical manuals between all types of publishing systems. This includes current batch and "WYSIWYG" systems, as well as future systems incorporating newer technology. This is accomplished by the interchange of style information, using the semantics described, to be used as input to the formatting system, whether human or computer. Given the diverse capabilities of the various types of systems, a number of assumptions and constraints are necessary. These are explained below. 10.2.3 Page integrity and page fidelity. Page Integrity in this specification is defined to mean the ability to preserve the exact same information on each page in a manual as it is exchanged between systems. This does not mean that the information will be presented exactly the same way, but only that it will appear between the same page boundaries. Page Fidelity is defined to mean the ability to preserve the exact presentation characteristics in addition to the same information on pages exchanged between systems. Preserving Page Fidelity between systems is not technically feasible with current technology. Preserving Page Integrity may be possible to some degree with today's technology, but has the following consequences: a. The pages may look different. b. Additional cost may be associated with the effort to ensure that the pages are identical in content and presented in a readable fashion. c. In order to preserve Page Integrity as much as possible and still adhere to the required FOSI, the author of the FOSI needs to be sure to include enough flexibility in the specification of characteristic values to allow pages to appear differently. d. Complete Page Integrity may not be compatible with arbitrary SGML documents and/or certain FOSI specifications. While complete Page Integrity is not supported by this specification, it is not precluded by it. Page Integrity requirements should be carefully reviewed in the context of applicability, usability, and cost. 10.2.4 Machine processability. FOSIs prepared in accordance with the Output Specification DTD in 50 are machine parseable. Machine parseability is defined here to include the ability for a machine to automatically verify that a FOSI contains all the required characteristic values and is presented in the correct syntax. 10.3 Organization of this appendix. The remainder of this appendix contains the following major sections: a. Section 20. Applicable Documents. b. Section 30. Output Specification (OS) Concepts. This section explains concepts that are important for a complete understanding of the OS. c. Section 40. Key to Characteristics. This section describes in detail the types of characteristics and the rules for applying them, including ranges of values when generating a FOSI, and summaries of all Characteristics in tabular form. d. Section 50. Output Specification (OS) DTD. e. Section 60. Guidelines. This section provides guidelines for an author of a FOSI. f. Section 70. Glossary. This section contains definitions of all significant terms used in the Output Specification. 20. APPLICABLE DOCUMENTS 20.1 Government documents. 20.1.1 Government standards. STANDARDS FEDERAL INFORMATION PROCESSING STANDARD FIPS PUB 152 - Standard Generalized Markup Language (SGML), adopted from ISO 8879 Information Processing - Text and Office Systems -- Standard Generalized Markup Language (SGML) (Copies of the Federal Information Processing Standards (FIPS) are available to Department of Defense activities from the Standardization Documents Order Desk, Building 4D, 700 Robbins Avenue, Philadelphia, PA 19111-5094. Others must request copies of FIPS from the National Technical Information Service, 5285 Port Royal Road, Springfield, VA 22161-2171.) 20.2 Non-Government publications. The following documents form a part of this document to the extent specified herein. Unless otherwise specified, the issues of the documents which are DoD adopted are those listed in the issue of the DODISS cited in the solicitation. Unless otherwise specified, the issues of documents not listed in the DODISS are the issues of the documents cited in the solicitation (see 6.2). AS4159 - Specification for Automatic Exchange of Standards Data ISO 8879 - Information Processing - Text and office systems - Standard Generalized Markup Language (SGML) ISO 9541 - Information Technology - Font Information Interchange Part 1 - Architecture - 1st Edition Part 2 - Interchange Format - 1st Edition Part 3 - Glyph Shape Representation ISO 9594 - Information Technology - Open Systems Interconnection - the Directory. (Copies are available from the Standardization Document Order Desk, Building 4D, 700 Robbins Ave, Philadelphia, PA 19111-5094, for issue to DoD activities only. All other requestors must obtain documents from the American National Standards Institute, 11 West 42nd Street, 13 Floor, New York, NY 10036.) 20.3 Order of precedence. In the event of a conflict between the text of this document and the references cited herein, (except for related associated detail specifications, specification sheets, or MS standards), the text of this document takes precedence. Nothing in this document, however, supersedes applicable laws and regulations unless a specific exemption has been obtained. 30. OUTPUT SPECIFICATION (OS) CONCEPTS 30.1 Introduction. The DTD contained in this appendix is a rigorous formalization of the functionality presented in section 40. The subsections of section 40 are reflected in the structure of the DTD, which is divided into seven major functional areas. The resource description, security description, and page description areas establish the information for page layout and other document- wide rules. The other four sections of the DTD, style description, table description, graphics description, and footnote description, provide the means by which elements in the source document are identified and define the processing that is to occur for each element. All elements that occur in the general style description (styldesc), table description (tabdesc), or graphics description (grphdesc) are placed into the flowing text area of the page. Elements that occur in the footnote description (ftndesc) are placed into the footnote area. The categories of characteristics as described in section 40 are represented in the DTD as elements. Individual characteristics are represented as attributes on those elements. The content models for elements may represent the interaction between categories. 30.1.1 Resource description (rsrcdesc). The resource description gives document-wide hyphenation rules, establishes strings, and provides descriptions of character fills, counters, and floating locations that will be used throughout the FOSI. 30.1.2 Security description (secdesc). The security description sets up the guidelines for handling variable security markings on a page. 30.1.3 Page description (pagedesc). The layout geometry of pages is defined in the page description area. Within this section, page sets (pageset) are established to reflect the different styles of pages that may need to be used within the document. Each page set describes a right-hand (rectopg), left-hand (versopg) page, a page to be used when the formatter generates a blank page (blankpg). The header and footer may be redefined when the formatter generates a recto page with a blank back (rectobb), or a verso page with a blank front (versobf). 30.1.4 Style description (styldesc). The style description provides the means for identifying elements-in-context (e-i-cs) in the source and the characteristics to be applied to them as they are processed. In addition, attribute values from the source document may be identified and additional processing specified. 30.1.5 Table description (tabdesc). Similar to the style description, elements that are processed as tables are identified and described through the table description. 30.1.6 Graphics description (grphdesc). Graphic elements are identified and described through the graphics description (grphdesc). 30.1.7 Footnote description (ftndesc). Footnote elements are defined in the footnote description area. Refer to 60.16 for further details. 30.2 Characteristics. A characteristic is a specification of a particular formatting property that a logical element is expected to have. In this appendix, characteristics have allowable ranges of values. In a FOSI, every characteristic has a value that specifies in some way how the processing system should treat the associated content. Composition characteristics are somewhat analogous to SGML attributes in that they are attached to logical elements. However they differ from SGML attributes in a couple of important ways: a. They are not part of the SGML source file, nor are rules governing their behavior covered by the SGML standard, ISO 8879. b. They are used specifically for describing the information a formatting system needs in order to format the document (see 30.4.3). Characteristics are descriptions of the format of a document, rather than commands that tell a formatting system what to do. In particular this OS is not a formatting language nor does it presume to direct how a formatting system should behave in order to accomplish the desired result. Characteristics are grouped into categories for ease of definition and use. There are two basic types of characteristics: Composition and Pagination. 30.2.1 Composition characteristics. Composition characteristics define how a particular element, when it is encountered, is to be treated. Composition characteristics are grouped into the following functional areas, each of which has a special subsection devoted to it in section 60: a. Style characteristics, which generally apply to all elements. (See 60.8) b. Table characteristics, which apply only to elements presented as a table. (See 60.15) c. Graphic characteristics, which apply only to elements presented as a graphic. (See 60.14) d. Footnote characteristics, which apply only to elements presented as a footnote. (See 60.16) 30.2.1.1 Composition characteristics and logical elements. It is convenient to think of logical elements as having an environment attached to them. An environment is the complete set of characteristics and their values that are currently in effect. The start-tag of an element opens or establishes an environment, and the end-tag of an element closes its environment and re-establishes the environment of its parent. 30.2.2 Pagination characteristics. Pagination characteristics define the layout of a page, independent of the elements occurring on that page. They are described in detail in 40.6. They define the following information: a. The physical aspects of pages (the page model), including size, margins, and areas for placement of text. b. How header, footer, and change mark areas appear on every page. c. Placement rules for floating logical elements. 30.2.2.1 Layout areas. Pagination characteristics differ from composition characteristics. Composition characteristics are attached to logical elements, whereas pagination characteristics are applied to the areas on a page within which logical elements are placed. These areas are referred to as "layout areas". Examples of Layout Areas are "column area" and "header area". Other than this basic difference, the application of characteristics is similar. A page model defines the structure of a page by specifying which Layout Areas are permissible, how these Layout Areas relate to each other, and what characteristics may be attached to them. 30.3 Value types. This section describes the eight types of values that characteristics are allowed to have. The actual values to be used are specified in a FOSI. Each kind of value is named and then explained. Allowable value ranges are included in this specification where appropriate. Where value ranges are specified in this appendix, a particular FOSI may only specify values from these ranges. Points are the basic unit of measurement used throughout this specification. A point is defined as being equal to 1/72 of an inch with a tolerance of +/- 0.4 percent. It is recognized that most typesetting systems use a more precise measurement for points, and that such systems may need to convert parameters given in points in a FOSI to another unit of measurement for use within their own system. Alternative units of measurement are allowed. The syntax to be used for expressing measurement in the allowable types of units is described below. Points shall be used as the default unit of measurement for the interchange of FOSIs. The use of points as the basic unit of measurement does not preclude any finer levels of precision. Finer levels of precision may be expressed as either tenths of a point or hundredths of a point. 30.3.1 Size/distance. This type of value is used generally for specifying characteristics that express measurement. The syntax for describing a Size/Distance value is number unit, for example "6pt" means 6 points. Numbers may be positive or negative, and may express precision in tenths or hundredths with the use of decimal points, for example, "6.4pt" means 6 and 4/10ths of a point. Each unit is expressed as a two letter abbreviation. Combinations of units are allowed, but must be completely specified; for example, to specify 5 picas and 3 points, the correct syntax is "5pi 3pt" (the space separating the two individual unit specifications is optional). Allowable expressions of units are: pi picas pt points in inches mm millimeters cm centimeters em em space 30.3.2 Integer. Integers are whole numbers that are either positive, zero, or negative. A "-" prefix to the magnitude designates a negative integer. Examples of correct values are "2", "14", and "-4". Examples of incorrect values are "3.324" and "6 3/4". Some characteristics are restricted to the use of positive Integer values. These are described where the individual characteristic is defined. An integer may be used to specify a percentage. 30.3.3 ID and IDREF. An ID is used to uniquely identify a characteristic or set of characteristics so that it can be referenced by an IDREF. ID and IDREF are used as in ISO 8879. 30.3.4 Pointer. Pointers are used to specify that information is contained in an external file. Pointers have the attribute type of "entity" and thus require an entity declaration in the FOSI declaration subset to identify the external file. The value "null" can be used as the value for a pointer when no information is relevant for a particular FOSI; an entity declaration for the value "null" is included in the OS DTD. 30.3.5 Finite list. This type of value is used where a finite and fixed set of choices is to be made for a particular characteristic. That is, wherever a finite list is specified, all legal values are explicitly contained in the list. For example, there is a well-defined short list of possible values for the Quadding characteristic (Flush Left, Justified, etc.). 30.3.6 String. A string is a literal sequence of characters. References to non-keyboard characters are made with an entity reference using the "&" delimiter and the name of the entity, followed by a semicolon, for example "†". To specify an "&" character when it is followed by a name character, use an entity reference for the ampersand (IV&V) which resolves to IV&V. A string differs from a finite list in that the values are not known in advance. When a string contains more than one value, values are separated by spaces. 30.3.7 Toggle. Zero and non-zero are used for toggling purposes. Zero is "0", and non-zero is any other integer, for example, "1" or "8" or "23". Zero is defined as 0, false, no, and off. Non-zero is defined as 1, true, yes, and on. 30.4 Specifying elements-in-context (e-i-c). In a FOSI, characteristics must be specified for each element in every context in which a formatting system needs to treat the element differently. That is, before characteristics can be attached to elements, the elements have to be completely specified. This is accomplished by providing the following information: Generic Identifier (GI) This is a unique name that identifies an element. (It may exist in the source DTD or be defined as a pseudo-element.) For a more detailed description of "generic identifier" see "Generic Identifier (GI) Specification" discussed in ISO 8879. Context The context characteristic gives the lineage of the GI. This specifies a context in which the element may appear (see 30.4.1.). Occurrence The order of appearance of this e-i-c in relation to like elements. All occurrences of an e-i-c within its parent, regardless of intervening elements of a different type, are considered part of one e-i-c group. For example, when a list contains item(1), item(2), note(1), and item(3), item(1) is the "first" item and item(3) is the "last" item. (See 30.4.2) 30.4.1 Context. The characteristics an element takes on may be a function of the particular lineage of parents it has when it occurs. For example, "title" has many uses and must be specified in context with its parent such as "Chapter" or "para0". In this case additional e-i-c entries may be necessary if the formatting requirements for the context of chapter are different than that of para0. To specify an e-i-c, the syntax described below shall be used. 30.4.1.1 Context characteristic syntax. The context characteristic gives the lineage of the GI. The context characteristic is a string of one or more GI(s) or wildcards separated by spaces. A wildcard is specified by a single asterisk. The first (leftmost) GI specifies the parent or most closely related ancestor of the element. Moving from left to right, subsequent GIs must be parents or ancestors of the previous GI. The wildcard can be used to specify zero or more levels of ancestry that are not referenced by name. When more than one wildcard appears in sequence in the context, it is considered to be one wildcard. Below are some examples. A chapter title: gi = "title" context = "chapter" A figure title in the body: gi = "title" context = "figure * body" A list within a warning: gi = "seqlist" context = "warning" A list within a warning within a primary paragraph: gi = "seqlist" context = "warning * para0" A list within a warning within front matter: gi = "seqlist" context = "warning * front" A list item within a list within a list within a list in a section: gi = "item" context = "seqlist * seqlist * seqlist * section" Any footnote in the front matter: gi = "ftnote" context = "front" A footnote in a table: gi = "ftnote" context = "entry" 30.4.1.2 Best matching e-i-c. Describes how to choose the e-i-c to use for any particular occurrence of an element within the document. 30.4.1.2.1 Terms. The following terms are used: a. CURRENT ELEMENT is the element of interest in the document. b. GI is the value of the generic identifier characteristic specified for the e-i-c in a FOSI. c. CURRENT PATH represents the current hierarchy in the document. It can be thought of as an ordered list of element names beginning with the parent of the current element, followed by its parent, etc., terminating with the document element. d. CONTEXT PATH represents a possible hierarchy that could appear in the document (based on the content models of the source DTD). It can be thought of as an ordered list of element names and wildcards. It is specified as the "context" characteristic for an e-i-c in a FOSI. e. NODE is a particular element name or wildcard in a path. f. CURRENT NODE is the node being currently examined in a path. g. CANDIDATE LIST is the list of e-i-cs that are possible choices (candidates) for being the best match. 30.4.1.2.2 Best match algorithm. The goal of the following algorithm is to determine which CONTEXT PATH most specifically matches the CURRENT PATH. The algorithm has two parts: first determining which e-i-cs are possible matches (creating the CANDIDATE LIST), then determining which one is the best path. A candidate list is first created without assuming any implicit initial wildcards, and then, only if that candidate list produces no matches, a new candidate list is made assuming implicit initial wildcards. The main algorithm for creating the CANDIDATE LIST is as follows: a. Put on the CANDIDATE LIST all the e-i-cs whose GI matches the CURRENT ELEMENT (and whose occurrence specification applies to the CURRENT ELEMENT). Repeat steps b and c for each candidate. b. Make the leftmost node the CURRENT NODE of both the CURRENT PATH and CONTEXT PATH. c. Does the subpath of the CONTEXT PATH starting with its CURRENT NODE match the subpath of the CURRENT PATH starting with its CURRENT NODE? (See following subalgorithm.) If not, remove the e-i-c from the CANDIDATE LIST. d. If no candidates remain, put on the CANDIDATE LIST all the e-i-cs whose GI matches the CURRENT ELEMENT (and whose occurrence specification applies to the CURRENT ELEMENT). Repeat steps b and c for each candidate, assuming that the CONTEXT PATH for each candidate contains an initial wildcard. For example, "chapter body" would now be interpreted as "* chapter body". The subalgorithm to determine if the subpath of the CONTEXT PATH starting with its CURRENT NODE matches the subpath of the CURRENT PATH starting with its CURRENT NODE is as follows: a. If the CURRENT NODE of the CONTEXT PATH is a wildcard then: 1. Move right in the CONTEXT PATH until the CURRENT NODE is not a wildcard or the end of the path is reached. If the end of the path is reached, the paths do match; exit this subalgorithm. 2. If the CURRENT NODE of the CONTEXT PATH does not match the CURRENT NODE of the CURRENT PATH, move right in the CURRENT PATH until its CURRENT NODE is the same as the CONTEXT PATH's CURRENT NODE or the end of the CURRENT PATH is reached. If the end of the path is reached, then the paths do not match; exit this subalgorithm. 3. Does the subpath of the CONTEXT PATH starting with the node to the right of the CURRENT NODE match the subpath of the CURRENT PATH starting with the node to the right of the CURRENT NODE? If not, make the next node to the right in the CURRENT PATH the current node and go back to step 2. 4. Else (i.e., the subpaths match), then the paths do match; exit this subalgorithm. b. Else (i.e., the CURRENT NODE of the CONTEXT PATH is not a wildcard): 1. If the CURRENT NODE of the CONTEXT PATH matches the CURRENT NODE of the CURRENT PATH: (a) Make the next node to the right the current node in both paths. (b) If we have reached the end of the CONTEXT PATH, then the paths do match; exit this subalgorithm. (c) Else if we have reached the end of the CURRENT PATH then the paths do not match; exit this subalgorithm. (d) Else go to step a of this subalgorithm. 2. Else, the paths do not match; exit this subalgorithm. Notice that step a.3 calls step a.2 recursively, and the phrase "exit this subalgorithm " always means to exit "up one level" to the calling algorithm. 30.4.1.2.3 Default match. If the candidate list produces no matches (that is, if there is no e-i-c entry in the FOSI for this source element), the result is left to be resolved by the output system. It is suggested in this case that the behavior be as if there were a matching e-i-c entry with an empty charlist. In this case, all characteristics that can default would default to the document description (docdesc). (See 60.9) 30.4.1.2.4 Best match evaluation. A unique best match is selected from the final candidate list by using the following algorithm. For each member in the candidate list, "line up" the nodes of the context path with the matching nodes in the current path (where a wildcard in the context path may "line up" with any number [possibly zero] of consecutive nodes in the current path). For each member, form a string by reading the expanded context path left to right and: (1) for every explicit node in the context path, append a 1 and (2) for every wildcard in the context path, append one more 0 than the number of nodes it matches. For example, if an asterisk in the context path matches 3 nodes in the current path, 4 zeros should be appended to the string. An initial decimal point should be inserted at the beginning of each string. These strings are used as the match score for the given member, the member. The candidate list with the highest score shall be the best match. Note that this algorithm puts more emphasis on matches near the beginning of the list and guarantees unique results. For example, consider the following current path and candidate list: CURRENT PATH: "para item randlist para step1 para0 chapter" CANDIDATE LIST: "para" "para item" "para * item" "para * para0" "para * randlist * chapter" "* para step1 * chapter" Below we show the results of "lining up" candidates with the current path. The number following each wildcard indicates the number of nodes in the current path it matches: CURRENT PATH: "para item randlist para step1 para0 chapter" CANDIDATE LIST: "para" = .1 "para item" = .11 "para *0 item" = .101 "para *4 para0" = .1000001 "para *1 randlist *3 chapter " = .100100001 "*3 para step1 *1 chapter" = .000011001 Evaluating each string as a number between zero and one we obtain a best match score of .11 for context="para item". 30.4.1.2.5 Implementation notes. Note that this algorithm produces absolute rather than relative values so that the determination of the match score of any candidate can be made before the complete candidate list is determined. In fact, the best match can be computed in parallel to the creation of the candidate list, and some potential candidates can be eliminated before being put on the candidate list by virtue of their match score being less than that of the best candidate to date. 30.4.1.2.6 Priority. This best match algorithm determines a unique match among all the possible unique context strings. However, if several e-i-c's have identical context strings and differ only by their occurrence attribute, the absolute best match will be that e-i-c with the highest priority occurrence value. If there is more than one e-i-c with the exact same context and occurrence, the first e-i-c encountered is the one that is used. 30.4.2 Occurrence. The occurrence attribute of the e-i-c element further refines the context in which this e-i-c is used by specifying the order of appearance of this e-i-c in relation to like elements with the same parent. All element instances with the same GI and the same parent element form a group out of which the occurrence indication can choose a subset. The possible occurrence values have the following meanings: a. Only: the element instance in question will match this e-i-c only if it is the only element (with this GI) in the group. b. First: only the first element in the group will match this e-i-c. (If the group only has one element, it will qualify as the First.) c. Last: only the last element in the group will match this e-i-c. (If the group only has one element, it will qualify as the Last.) d. Middle: all elements except the first and last in the group will match this e-i-c. (If the group has less than three elements, no element in the group will qualify as the Middle.) e. Notlast: all elements except the last in the group will match this e-i-c. (If the group only has one element, it will not qualify as the Notlast. If the group only has two elements, the first one will qualify as the Notlast.) f. Notfirst: all elements except the first in the group will match this e-i-c. (If the group only has one element, it will not qualify as the Notfirst. If the group only has two elements, the last one will qualify as the Notfirst.) g. All (the default): all elements in the group will match this e-i-c. Note that a given element instance may qualify for more than one occurrence value in which case the best match is determined by the priority of the occurrence values for which it qualifies. The priority of occurrence values (from highest to lowest) is: only, first, last, middle, notlast, notfirst, all. 30.4.3 Source document attributes. The charlist should be written to specify the formatting intent for an element that will have no attributes attached to it (e.g., <para0> versus <para0 tocentry="1" label="INTRO">). The value assigned to attributes through the SGML markup may affect the characteristics assigned to an e-i-c. There are three possibilities: a. The attribute has no effect on formatting. For example, an attribute in the source document which provides identification, such as part number. b. The attribute's value affects which characteristics are activated, but does not specify the value of the characteristic. For example, the value associated with an attribute used to indicate if a table of contents entry is desired for an element in the source document. Such an attribute is used by the FOSI to either extract or not extract the corresponding content to the table of contents. c. The attribute's value must be used as a characteristic value. In other words, the attribute value is directly assigned to a characteristic value. For example, from the source document, an attribute used to indicate the number of columns in a table supplies that value to the FOSI for use in determining the final appearance of the table. The att allows the user to qualify the formatting intent based upon possible attribute occurrences. In other words, based upon the appearance of a certain attribute value or by extracting an attribute value >from the source instance the user is permitted to specify additional formatting intent or override the characteristics that were specified in the original charlist. The mechanisms for handling these cases (with the exception of the first which requires no special treatment) are specval and fillval. These mechanisms, used alone, or together, enable the FOSI author to specify the attribute(s) that affect characteristic values specified in the resulting charlist. The following pargraphs list and describe these characteristics. 30.4.3.1 SPECVAL. - This category is used for the case where the attribute affects the use of a characteristic but does not supply the value of the characteristic. The charsubset associated with the SPECVAL will take effect when the attribute specified by attname contains the value specified by attval. It has the following characteristics associated with it: a. ATTNAME. The name of the source attribute that is being identified as having an effect on formatting. When the attname value does not specify the name of a valid attribute, the specval will be considered to be unsatisfied and the associated characteristic values for this attribute section are not applicable. b. ATTLOC. The name of the element on which the attribute was specified. If unspecified, it is assumed to be the same as the "GI" for the e-i-c being described. If specified, the name should be the name of an ancestor of the e-i-c and indicates the most immediate previous ancestor of that name. This allows referencing the values of ancestors' attributes to determine formatting of the current element. Alternatively, this field will contain the keyword #FOSI to indicate that ATTNAME is the name of an internal FOSI variable rather than a source attribute. When the attloc value does not specify the name of a valid ancestor of the current e-i-c or the attname value does not specify the name of a valid source attribute for this ancestor, the specval will be considered to be unsatisfied and the associated characteristic values for this attribute section are not applicable. c. ATTVAL. The value for the attribute identified in "ATTNAME" which results in a certain formatting difference. Specval has the following basic SGML structure: <e-i-c gi="element"> <charlist> characteristics without respect to attributes <att logic="or"> <specval attname="name of attribute (on element specified by attloc) specified in source" attloc="name of an ancestor of an element" attval="value contained in attname"> <charsubset> characteristics to take effect if specval is satisfied 30.4.3.1.1 Evaluating a specval. A specval is considered to be satisfied when the source attribute specified by attname (and optionally attloc) has been assigned the value indicated by attval. If an att is satisfied, the associated characteristic values (from the charsubset) must be "merged" into the charlist for this e-i-c. Most categories (e.g., font) can only occur once in a charlist, but some (e.g., savetext, puttext) may occur multiple times and "merging" has a different meaning in these two cases. 30.4.3.1.2 Specval syntax. For a specval, the value for attval should represent one of the possible values that an attribute can have. In addition, the following key words can be used: a. #NONZERO may be supplied for attributes whose declared value is a number (not CDATA) to indicate any value that does not consist of zero or more blanks followed by one or more zero characters followed by zero or more blanks. b. #NONE indicates that no assignment was made to that attribute in the source document. Note that this condition is possible only when the attribute has a default value of #IMPLIED. c. #ANY may be used for any attribute to indicate that an assignment was made in the source document. d. #ITEM#YYY may be used to indicate that the value of attval contains one item from a list, where YYY is a literal. For example, #ITEM# would be used for an attribute with a declared value of NAMES. In this case the characteristics specified for all of the items for one attribute are cumulative where possible; all the values take effect instead of overriding one another. One case may be highlighting, which has numerous formatting options available. e. #XX#YYY may be used for attributes whose declared value is a number where XX is one of the letter pairs LT, GT, EQ, LE, GE, NE and YYY is a numeric constant or counter id (enumid). In this case, the specval will be satisfied if the value assigned to the given source document attribute is, respectively, less than, greater than, equal to, less than or equal to, greater than or equal to, or not equal to the given numeric constant or current value of the given counter. The same syntax may be used for attributes whose declared value is not a number, but in this case XX can only be EQ or NE and YYY is a backslash delimited literal or a savetext name. In this case, if the declared value of the attribute is CDATA, the comparison will be case sensitive, otherwise it will not be case sensitive. 30.4.3.1.3 Merging charsubset into charlist. If a specval's charsubset contains a category that is permitted zero or one time in the charlist by the OS DTD (such as font), that category's settings in the charsubset merge by replacing any settings of the same characteristic in the charlist. (Note: only those characteristics explicitly set in the charsubset will replace values in the charlist, characteristics in the same category that are not explicitly specified in the charsubset are not modified in the charlist.) However, if a charsubset contains a category that is permitted zero or more times in a charlist by the OS DTD (such as savetext or puttext), the category's settings in the charsubset should merge by accumulating with all occurrences of the same category in the charlist and any other charsubset. That is, for all occurrences of repeating categories in an att whose condition set is satisfied, the behavior should be as if these categories were in the charlist (in the order they appear in the e-i-c's entry). 30.4.3.2 FILLVAL. This category is used for the case where the attribute's value is used as a characteristic value. For this case additional characteristics for the corresponding category may be filled in the Characteristic Subset List (charsubset) immediately following the fillval (or sequence of fillval) category(s). It has the following characteristics associated with it: a. ATTNAME. Same as SPECVAL. b. ATTLOC. Same as SPECVAL. c. FILLCAT. The OS category for which the source attribute has an effect. d. FILLCHAR. The characteristic found in the category specified in "FILLCAT" for which the value from the source attribute is to be assigned. e. CONRULE. Rules for specifying the construction of the filled value. Fillval has the following basic structure: <e-i-c gi="element"> <charlist> characteristics without respect to attributes <att logic="or"> <fillval attname="name of attribute (on element specified by attloc) specified in source" attloc="name of a direct ancestor of element" fillcat="charlist category name to be used" fillchar="category characteristic name to fill value into"> <charsubset> all remaining characteristics that are affected by the appearance of the source attribute 30.4.3.2.1 Evaluating a fillval. A fillval is considered to be satisfied when the source attribute specified by attname (and optionally attloc) has been assigned a value in the source instance (either explicitly or due to an explicit default being specified in the source DTD). If an att is satisfied, the associated characteristic values (from the charsubset) must be "merged" into the charlist for this e-i-c. Most categories (e.g., font) can only occur once in a charlist, but some (e.g., savetext, puttext) may occur multiple times, and "merging" has a different meaning in these two cases. A fillchar may also get merged into the charsubset and then merged into the e-i-c's charlist. 30.4.3.2.2 Fillval syntax. For a fillval, the value of fillcat should be the name of characteristic category (one of the GIs in the content model for "charlist" in the OS DTD or appropriate table, figure, and graphics characteristics) and the value for fillchar should be the name of a characteristic (one of the attributes associated with those GIs in the OS DTD). If no Construction Rule is specified, the source attribute value is assigned to the specified characteristic with no modification. When a Construction Rule is specified, the source attribute value is designated by #CONTENT, and the resolved Construction Rule is assigned to the specified characteristic. (See 40.3.26 for the syntax of a Construction Rule). Characteristic values that were not specified in the fillval, or sequence of fillvals, are filled in for the designated category. 30.4.3.3 Multiple fillval and specval specifications. When there are multiple specvals and fillvals contained in a single att, all of the specvals and fillvals in the att are first evaluated, then the value of the logic attribute is evaluated to determine what conditions must be met in order to satisfy the att. When the logic attribute is "or", at least one of the specvals or fillvals must be satisfied in order for that att to be satisfied. When the logic attribute is "and" all the specvals and fillvals in the att must be satisfied in order for that att to be satisfied. 30.4.4 Pseudo-elements. Generally the GI of an e-i-c entry in the FOSI identifies an element in the source DTD. However, the GI may also name a "pseudo-element" that does not conflict with the name of any element in the source DTD. This pseudo-element could be included in the Construction Rule of a Savetext or the Source of a Usetext. The formatting characteristics would take effect when that pseudo-element is used via the Usetext category. Note that a pseudo-element does not appear in the source DTD, but only in the FOSI. The pseudo-element is a construct that can act as a reference to an e-i-c entry in the FOSI. Pseudo-elements do not have attributes and the e-i-c entry can therefore not have attributes, but the pseudo-elements do require end-tags. 30.5 Inheritance and defaulting. There are many characteristics that can potentially be specified in a charlist. In practice, however, most e-i-cs omit explicit specifications for many of the characteristics. The use of inheritance within a FOSI provides a means for avoiding the explicit specification of every characteristic value for each in cases where the value seldom changes from one element to the next. Inheritance and defaulting provide mechanisms for determining values for unspecified characteristics in an e-i-c's charlist. [Note that inheritance and defaulting occurs relative to an e-i-c's "resolved charlist". This is the logical charlist that results after merging of all appropriate attribute specifications (specval's and fillvals) and charsubsets. Sub-characteristic lists (subchars) usually specify only a small set of characteristics. Although in a strict sense, inheritance and defaulting does not apply to subchars, the mechanism by which the remaining characteristics that are associated with the subchars are determined is quite similar to the inheritance and defaulting rules for charlists.] When a characteristic has an explicit assignment in a charlist, this determines the value of the characteristic (though in some special cases e.g., keeps, suppress, prespace, and postspace - the determined characteristic value may be ignored or modified due to the particular definition of the effect of the characteristic). When a characteristic has no explicit assignment in a charlist, how its value is determined differs depending on whether its category is inheritable (i.e., includes an inherit characteristic) or not. An inherit characteristic can have the value "off" (zero) to indicate that inheritance is not enabled for this category occurrence or a value of "on" (non-zero) to indicate that inheritance is enabled for this category occurrence. If a category's inherit characteristic is not explicitly assigned, its value will default to the value of the charlist's inherit attribute (which always has a value since the OS DTD assigns it a default value of "off"). a. For inheritable categories: 1. If an inheritable category is omitted entirely from a charlist, the effect should be as if the category were specified with no explicit characteristic assignments but with the inherit characteristic set to the value of the (possibly defaulted) charlist's inherit characteristic. That is, when an inheritable category is omitted from the charlist, if the charlist inherit is "on", inheritance is enabled for this category (see paragraph a.2. below), whereas if the charlist inherit is "off", inheritance is not enabled for this category (see paragraph a.3. below). 2. If inheritance is enabled for this category (i.e., the value of the inherit characteristic is set "on" either explicitly or by virtue of defaulting to the value of the charlist inherit characteristic), the characteristics in this category that are not explicitly assigned values inherit their respective values from the parent element instance in the source document. 3. If inheritance is not enabled for this category, the characteristics in this category that are not explicitly assigned values obtain their respective values from the environment indicated by the environment name (envname) attribute of the charlist. If no environment name is specified, the values are obtained from the default environment (docdesc). b. For uninheritable categories: 1. If an uninheritable category is omitted entirely from a charlist, no processing relative to that category occurs, and the values of its characteristics are unaffected. 2. If the category appears in the charlist, characteristics not explicitly assigned values obtain their respective values from the environment indicated by the environment name (envname) attribute of the charlist. If no environment name is specified, the values are obtained from the default environment (docdesc). c. If after inheriting and/or defaulting as specified above, there is still no value assigned to a characteristic, then either that characteristic has no affect in the current situation or its value is left to be resolved by the output system. (Certain values, such as that for letterspace or wordspace, may be best optimized by the output system.) In sub-characteristic lists (subchars), all unspecified categories that can be inherited behave as though the category was specified with its Inherit characteristic enabled (that is, a Subcharacteristic List behaves in the same way as a Characteristic List whose Inherit attribute is enabled). Each specified inheritable category inherits or defaults (depending on the setting of its Inherit characteristic as described above in step a); sub-characteristic that are inherited take the resolved value for this characteristic from the encompassing charlist. All categories that cannot be inherited default (as described above in step b) to the same environment to which the containing charlist defaults. For the Change Mark and ruling categories which have non-empty content other than subchars, inheritance and defaulting work the same as with subchars; that is, the rules for inheritance and defaulting are as if the categories in the content of Change Mark and Ruling where wrapped by a subchars element. Inheritance on the outermost (doc) element should be interpreted as being equivalent to defaulting to the default environment in effect for that tag. It is the responsibility of the FOSI writer to make careful use of inheritance. A charlist subset (charsubset) has both charsubsetid and charsubsetref attributes. These attributes provide for referencing specific charsubsets in charlists, atts, or other charsubsets, for example. The use of charsubsets in a charlist allows for replacing specific characteristics, while still inheriting characteristics from the parent. An environment description (envdesc) contains a Characteristic List (charlist) which has "inherit" and "envname" attributes. The "inherit" attribute on the charlist in an envdesc will be ignored; that is, it will always be treated as if it were set to zero (do not inherit). All the inherit attributes on the categories in an envdesc's charlist are also ignored. The "envname" attribute on the charlist in an envdesc can specify the name of an already declared envdesc; any characteristic not explicitly specified in an envdesc will be given the value from the default environment named by "envname" (which must have been declared previously in the FOSI). Note that if the "envname" attribute is not specified on the charlist of the envdesc, the envname would default to the docdesc. Therefore any characteristic in a category that is not specified for this environment would take on the values as assigned in the default environment. Note, since an environment description provides defaults for unspecified characteristics, it is inappropriate for any category to appear more than once in the same environment description. Notice, for a charlist in an e-i-c (as opposed to an envdesc), both the inherit and envname attributes are relevant. The charlist's inherit value takes effect only for inheritable categories with no explicit setting for the inheritance value. Any characteristic in an explicitly mentioned category that is neither explicitly specified nor inherited (either because it is not inheritable or because its category's inherit characteristic is "off") would derive its value from the default environment. Figure 1 helps to explain the movement through the inheritance and defaulting procedure. 30.6 Order of processing. Though there are generally characteristics associated with e-i-cs in a time-independent manner, the order of processing of certain constructs is significant. In particular, since multiple Savetext Construction Rules and Usetext Sources can refer to counters and other saved text, the order of processing is significant. Furthermore, since Savetext, Usetext, Reset, and Enumerate characteristics can occur within the current element's contents (potentially changing values referenced in other Savetext, Usetext, and Enumerate characteristics), whether a Savetext or Usetext is processed before or after the content of the element gets processed is also significant. For any e-i-c instance, the order of processing should be as follows: a. The charsubsets referenced by the charlist charsubsetref attribute are "merged" in the order they are listed; then the explicit main charlist is "merged" with the result, then inheritance and defaulting occur to form the overall (resolved) main charlist. The attribute specifications are resolved by "merging" as appropriate the characteristics/categories into the main charlist (see 30.4.3.1.3). b. The resulting charlist is now processed sequentially, except for any Savetext, Ruling, Puttext, Putgraph, or Usetext category entries whose placement characteristic is "after". Note that the value of any variables (either Counter IDs or Savetext textids) that appear in the Savetext Conrule or Usetext Source is resolved at the time that Savetext or Usetext is processed. Any pseudo-elements that appear in the Savetext Conrule are processed (including the complete processing of the charlist associated with that pseudo-element) when the Savetext textid is processed in a Usetext source. A Usetext Source that contains several variables and/or pseudo-elements is processed as if the complex Source is saved via a Savetext to a virtual textid and then the virtual textid is immediately used in this Usetext. That is, any pseudo-elements that appear in the Usetext Source are processed in order immediately after all variables in that Usetext are resolved. c. After the contents of the e-i-c is processed, all Savetext, Ruling, Puttext, Putgraph, or Usetext category entries whose placement characteristic is "after" (including their subchars) are processed in the order they were specified in the charlist. d. Processing of a category that contains a subchars begins by processing the content of the subchars followed by the processing for the category itself. The rules for the processing order within a subchars are the same as those for processing a charlist. 30.7 Security. Most technical manuals require that an indication of the highest level of security found on a page or sheet appear in the running header and/or footer. Each element in the source document may have a security attribute in which the security level for its content is indicated. The Security Description is used to specify the precedence of these security values and the strings that should be automatically generated to indicate the classification level. Security text is then identified in the header and footer areas and its value is computed according to the values of the security attributes of the content that appears within the scope indicated. The scope can be a page, sheet, or the entire document. 30.8 Color. The use of color in formatting can be specified in several areas of the Output Specification, including highlighting text, graphics, and rules. Specification of color is intended for use with "spot color" techniques; that is, a single color is used for any particular text character, graphic, rule, or background with no "merging" of colors. The color is to be used full strength except when screens are specified, in which case a percentage of full strength should be used. Within the OS, the following generic colors are allowed: black, white, red, orange, yellow, green, blue, violet, brown, and gray. It is up to the formatting system to determine the exact color used for printing or display. 30.9 Floating constructs. The general composition model of almost all document processing systems is sequential: the document is processed from front to back (in document order) and the input content is composed onto the output pages so that the information is presented basically in the same order in which it was input. There are some notable exceptions to this paradigm; among them are various kinds of "floating" blocks of material, cross references, content replicated in tables of contents, indexes, or similar constructs, text from the input content placed into running headers or footers, etc. In the Output Specification, the Savetext and Usetext constructs can be used to handle most of these needs with the exception of floating blocks of material. Footnote processing is one case of floating that has special handling in the Output Specification. The Output Specification has a generalized mechanism to handle all other floats. This mechanism allows for any element-in-context (e-i-c) to specify that its contents should float to some other place in the output instance than the next available location in the flowing text area. The mechanism allows for three different floating behaviors: (1) floating material into an area on the current or nearby page at the top or bottom of a column or page; (2) floating material into an area at the top or bottom of the current column or page in such a fashion as to provide a mechanism for repeating floating elements across page breaks (e.g., repeated captions); and (3) floating material in a fashion similar to that of footnotes in such a fashion that multiple references to identical floats on the same page result in only one copy of the float to appear in the floating location on the page (as might be the case with footnotes within tables or trademark and corresponding legends). Specifying floating involves three steps: 1. defining the characteristics of the floating layout area in the resource description; 2. attaching a floating layout area to a page model in the page description; 3. specifying for each e-i-c to be floated the floating layout area into which it is to be floated. The float specifications in the Output Specification provide the output system with various constraints within which to attempt to lay out the result. The constraints must be specified so as to leave the output system some flexibility, since different composition systems will necessarily use different page layout algorithms. Using the Output Specification's floating mechanism, it is possible to provide constraints that cannot be satisfied. In this case, the output system may either issue an error or attempt some resolution that does not satisfy all the constraints. The FOSI writer should avoid writing specifications that lead to improperly constrained situations. The float category interacts with other categories in that floating determines only layout position by the normal inheriting and defaulting procedures. The formatting properties of surrounding elements are unaffected by the floated element. 1. Multipage objects can be floated, though certain specifications (such as "float to the facing page") will lead to improperly constrained situations. When the multipage floated object is placed into the output stream by the output system, the multipage object will be placed on subsequent pages according to the output system's page breaking and float placement algorithms. 2. Pre- and postspace are applied in the normal manner and affect spacing in the float location. The postspace of the e-i-c that precedes the floating e-i-c and the prespace of the e-i-c that follows interact in the usual way of adjacent pre/postspace. 3. A Span specification in the charlist of the e-i-c instance that is floating affects the material that floats. However, the material that does not float is not interrupted and balanced, but rather continues in the flow text area as formatted. 4. Keep previous and keep next on the e-i-c instance that is floating has no meaning and is ignored. 5. Textbreak characteristics of startln and endln are both treated as if they were set on ("1"). Startcol has no meaning and is ignored. The characteristics startpg, newpgmdl, and pageid are relevant for the floating material (but have no affect on the material that does not float) as follows: if startpg="1" and newpmdl=local, then the floating element begins on a new page and the pageset specified by the pageid is used for the duration of the floating element's content. This allows, for example, the floating of an element into a series of landscape pages. (A value of newpmdl=global is treated as if newpmdl=local when the e-i-c instance in question floats.) 40. KEY TO CHARACTERISTICS In the following subsections each Category of Composition Characteristics is described in detail, according to the following structure: a. Category Name b. Category Definition c. Table of Characteristics and Types of Values allowed d. Explanation notes and points of clarification Definitions are provided for characteristics where appropriate, and restrictions on values are noted where applicable. Although this section contains some examples, it is meant to be used as a reference section, and not as a guide or tutorial. Further clarification on the actual application of characteristics in a FOSI may be obtained by studying the Output Specification DTD in section 50. 40.1 Resource description characteristics. 40.1.1 Hyphenation rules. The process of breaking a word at the end of a line of text for purposes of line justification. Characteristics - Definitions: Values - Definitions Language ID Dictionary Pointer Word Break Exceptions - A specification Pointer for preferred hyphenation points. Unbreakable Words - A specification for Pointer words with no allowable hyphenation points. Break Characters - Characters which can be String broken before or after without inserting a hyphenation character. Break Before Characters - Characters which String can be broken before without inserting a hyphenation character. Break After Characters - Characters which String can be broken after without inserting a hyphenation character. No-break characters - Characters before or String after which it is not legal to break. Hyphenation Type - Specification of the List (Dictionary, method for making hyphenation decisions. Logic, Both, Any) Hyphenation Zone - Specifies the amount of Size/Distance space from the margin that can be left by choosing not to hyphenate (aesthetic rag). Ladder - The number of consecutive lines in Integer a column that can end with a hyphenation character. Minimum characters left on a line. Integer Minimum characters pushed to the next line. Integer Hyphenation across columns allowed. Toggle Hyphenation across pages allowed. Toggle EXPLANATION: a. Using the hyphrule's language attribute and the hyphen category's "lang" characteristic, any e-i-c can refer to a particular one of the multiple hyphrules thereby allowing one to change hyphenation schemes within a document. (A given implementation may restrict the granularity at which one can change hyphenation schemes.) b. The dict attribute allows one to specify a (non-exception) dictionary, since with multiple hyphrules, there can be multiple (non-exception) dictionaries. Exactly how this dictionary is accessed and what its format may be depends on the value of the Hyphenation Type characteristic and the output system. c. Discretionary hyphens are accommodated through the Word Break Exception List. d. Word Break Exceptions always take precedence. e. The syntax to be used for Word Break Exceptions requires each word to be separated by a comma and/or a space, with each hyphenation point marked by a hyphen, for example, "ref-er-ence, syn-tax". The use of double hyphens indicate a fixed hyphen, for example, MIL--M--28001. f. The syntax to be used for Unbreakable Words requires each word to be separated by either a comma and/or an optional space. g. Break and No-break Characters are specified in a string value separated by blanks. h. The Hyphenation Type specifies the general method that the composition system should use to make hyphenation decisions. "Dictionary" specifies that all hyphenation decisions occur based on lookup in some dictionary; however, dictionaries are not interchanged because they may be proprietary. A specific dictionary may be specified per contract. Likewise, "Logic" specifies an algorithmic approach, but no algorithms are interchanged. "Both" specifies a combination of the two approaches, and "Any" specifies that any approach is allowed. 40.1.2 Character fill. Describes a literal used to fill a space horizontally or vertically. Characteristics - Definitions: Values - Definitions: Character Fill literal - The String character string. Orientation - The direction of List (Vertical - fill is down the fill. from baseline. Horizontal - fill is to the right from cursor). Type List (RR - Ragged left, Ragged right; RF - Ragged left, Flush right; FF - Flush left, Flush right; FR - Flush left, Ragged right) Space Before - Minimum spacing Size/Distance before the first occurrence of the specified literal in the fill. Space After - Spacing after Size/Distance the last occurrence of the specified literal in the fill. Padding - Spacing between Size/Distance occurrences of the specified literal. Truncation - Whether the last Toggle copy of the literal string can be truncated. Suppression Rules - Do not Integer apply fill if less than this many copies of the literal string would appear. Alignment - Vertical alignment Toggle of the fill literal. Character Fill ID - a unique ID name for the character fill. EXPLANATION: a. The Type characteristic determines where the literal begins and ends. "Ragged" specifies that the literal begins and/or ends immediately after and/or before the text it abuts. "Flush" specifies that all literals begin and/or end at a "margin" determined by the longest text before and/or after the literal. b. When the Alignment characteristic has a value of "on", the Literal shall align vertically on successive lines. When the value is "off", the Literal shall immediately succeed the previous character on each line. c. Specifying Character Fill only sets up the characteristics for a character fill string. To actually specify the position of the string in the output, the Character Fill ID must be used in the Source of a Usetext specification (either directly or through its inclusion in a Construction Rule of a Savetext) 40.1.3 Counter. This construct is used to specify the properties of a counter that will be associated with one or more e-i-cs using the Enumerate category. Characteristics - Definitions: Values - Definitions: Initial - The initialized value Size/Distance of a counter. Style - The style in which the List (Arabic, Roman Upper, Roman counter is to be displayed. Lower, Alpha Upper, Alpha Lower, User Defined) Specified Style - A user- String defined list of characters or symbols in order of precedence, for example, "* ** # ## ...". Sequence - Used to describe List (1, 2) the sequence for alphabetic display of counters exceeding 26. Padding length - Used to Integer describe the minimum number of characters in the string resulting from the conversion of a counter into arabic style. Exceptions - Used to list any String exceptions to the Style or Sequence. For instance, if the style is Alpha Upper, "I" and "O" might be exceptions. Counter ID - A unique name ID assigned to a counter. EXPLANATION: a. When the Style characteristic is "User Defined", the value of the Specified Style is used to determine the values for the enumeration counter. When the Style characteristic has any other value, the Specified Style is ignored. b. The Sequence characteristic does not apply when the value of the Style characteristic is "Arabic", "Roman Upper", "Roman Lower" or "User Defined". The result is either upper case when the Style characteristic is "upper", or lower case when the Style characteristic is "lower". Following are the sequence rules for enumeration (counters): 1. Following "Z" continue enumeration with: AA, AB, AC, ...AZ, BA, BB, BC, ..., BZ, ..., ZA, ... ZZ. 2. Following "Z" continue enumeration with: AA, BB, CC, ...ZZ, AAA, BBB, CCC, ...ZZZ. c. Compound numbers are specified through the Construction Rule of the Savetext characteristic. d. A counter value of 1 shall correspond to the first symbol in the set of characters implied by the Style or determined by the Sequence. (For example, a value of 3 would correspond to III, iii, C, and c for Styles of Roman Upper, Roman Lower, Alpha Upper, and Alpha Lower respectively.) When the Style is other than Arabic, what to do with a counter value of zero is left to be resolved by the output system. e. The padding length characteristic is a positive integer giving the desired final length in characters of the string that gets placed into the output stream whenever this counter is used in a Usetext Source (or into the Savetext textid variable when used in the Savetext Construction Rule). This length is achieved by padding the character representation of the current value of the counter on the left with zeros. The padding length is ignored except for a Style specification of Arabic (either in the counter declaration or via a local overriding style specification in the Construction Rule or Source). 40.1.4 String. This construct is used to specify the properties of a string that will be associated with one or more e-i-cs using the savetext or usetext category. Characteristics - Definitions: Values - Definitions: Savetext Name - A unique name NMTOKEN for the saved text. Literal - The initial string value. String Time Status - Indicates whether Toggle this variable is time dependent (0) or time independent (1). Scope NAME EXPLANATION: a. The Savetext Name follows the same rules as that for the Savetext category; the Literal follows the same rules as that for the Puttext category. b. A Time Status of zero (disabled) indicates that the variable named by the Savetext Name is time dependent. That is, the value of the variable will be evaluated at the time it is referenced in a Savetext Construction Rule or Usetext Source. A Time Status of one (enabled) indicates that the variable is time independent; that is, the value that is used to replace this Savetext Name everywhere this variable appears is the value this variable would have before the end of its scope. All time independent variables must be declared using the String construct; any variable not declared will be time dependent. c. In the case of time independent variables, the contents of the variable named by the Savetext Name will be resolved after the element specified by the Scope characteristic has ended and been completely processed. The element specified by the Scope characteristic must be an ancestor of the e-i-c instance in which this instance occurs; if not, the variable will be resolved at the end of the document element. 40.1.5 Floating locations. A float location is similar to a layout area in the page model. Elements float into a float location at the time the float category (in a charlist or subchars or charsubset) is encountered. Floats in a given float location are maintained in a first-in-first-out order except that certain combinations of specifications (such as a float with pagetype=next followed by one with pagetype=same) can provide constraints that contradict the first-in-first-out principle, in which case the output system may choose to violate the first-in-first-out principle as part of its fallback resolution. Characteristics - Definitions Values - Definitions Float ID - A unique ID for this floating ID location. Float Type - Indicates the kind of float List (Once, Repeat At Page Break, emission behavior. Repeat at Column Break, Multi-reference) Maximum Depth - The maximum extent to Size/Distance which this area can grow on any given output page. Mininum - The least amount of space that Size/Distance can appear Nominal - The preferred amount of space Size/Distance (what should appear) Maximum - The greatest amount of space Size/Distance that can appear EXPLANATION: a. A floatid identifies the float location so that it can be referenced by the elements that are to float into it. (Float Ids are also referenced in the Page Description and possibly in the Keeps and Reset categories.) b. The maximum depth is a dimension specifying the maximum depth of the layout area for any one page. c. A vertical spacing amount defined by minimum, nominal, and maximum separates the layout area from the (column or flowing text) text area or from the adjacent float layout area. That is, for each float location instance on a given output page, any pre-/postspace on the "text-side" of the float location area (e.g., initial space for bottom floats and final space for top floats) is ignored and replaced by this vertical spacing amount. Furthermore, any initial prespace of the first float location at the top of the page and any final postspace of the last float location at the bottom of the page are ignored so that the outermost float abuts the next outer layout area on the page (e.g., the "Space Above" area in the case of the first float location at the top of the flowing text area). Between individual floats within a single float location, the pre-/postspace specified in each floated element combines in the usual way with the pre-/postspace of adjacent floats. d. The output system will place floats associated with a given float location onto output pages in first-in-first-out order within the various constraints of page location, page type, float and float location width, and maximum depths. Where it is not possible to satisfy all constraints, the output system can issue an error message or employ some fallback algorithm. e. Most floats (whose Float Type is Once) appear once and only once for each reference in the flowtext. However, if Float Type is Repeat At Page Break, the material in this float location will be repeated at each page break until the scope of this floated material ends. Finally, if Float Type is Multi-reference, the float appears exactly once per page for any page from which this float was referenced one or more times. 40.2 Security description characteristics. 40.2.1 Security description. Defines the security levels and the priority order of the levels. Characteristics - Definitions: Values - Definitions: Attribute specification String Security order List Ignore security String EXPLANATION: a. The attribute specification characteristic is used to identify the attribute used in the source document to indicate the security levels. b. The security order characteristic is used to list the priority order of the security levels, for example, "s c u", where "s" indicates the highest level and "u" indicates the lowest level. c. When security considerations are not applicable, the Ignore Security characteristic indicates the value of the security attribute of the document element that indicates security processing should not be done. In this case, security tokens specified in headers and footers will not be replaced with any security text. For example, when Ignore Security is set to "u" and the security attribute of the document element is set to "u" (e.g., <doc security="u">), no security text appears in the headers or footers. 40.2.2 Security token. Defines the security markings that appear in the header and footer as specified by the "sectext" element. Characteristics - Definitions: Values - Definitions: Security value String Security text String EXPLANATION: a. For each value specified in the Security Order, a corresponding Security Text string can be specified. When a security token occurs in a header or footer, the highest level of security occurring on the page is computed and, the Security Text associated with that value is used as the content of the "sectext" element. If no Security Text is associated with a security level, no text appears. 40.3 Composition - text, style description characteristics. 40.3.1 Font. A collection of (character) images having the same basic design. Characteristics - Definitions: Values - Definitions: Inherit Toggle Style List (serif, sanserif, monospaced serif, monospaced sanserif) Family Name String Size Size/Distance Posture List (Upright, Oblique, Back slanted oblique, Italic, Back slanted italic) Weight List (Ultra light, Extra light, Light, Semi light, Medium, Semi bold, Bold, Extra bold, Ultra bold) Proportionate Width List (Ultra condensed, Extra condensed, Condensed, Semi condensed, Medium, Semi expanded, Expanded, Extra expanded, Ultra expanded) Small Caps Toggle Baseline Offset Size/Distance EXPLANATION: a. The Family Name value need not match one of the Style values, but should designate the actual family used as named by the manufacturer of the font family. Family Name values need only be supplied for optional use by the receiving system. If the Family Name is non-null, then, in the case of a conflict between the Family Name and the Style, the Family Name would take precedence over the Style specification by a system that uses family names. b. Only positive values are allowed for the Size characteristic. c. A positive value for the Baseline Offset indicates a distance above the text baseline; a negative value indicates a distance below. 40.3.2 Leading. The amount of space between the baselines of text lines in a single element. Characteristics - Definitions: Values - Definitions: Inherit Toggle Leading Size/Distance Force Leading Toggle EXPLANATION: a. Only non-negative values are allowed for Leading. b. When the Force Leading toggle is enabled, the leading for each line will be equal to the largest leading set on an element on that line. When the Force Leading toggle is not enabled, the leading will be equal to the first leading set in an element in which no children specify a new line (via Textbreak's startln or endln); however, the output system will increase the leading as required on any given line to avoid overprinting of text. c. Leading applies to all lines of text including the first line of an element. 40.3.3 Hyphenation. The process of breaking a word at the end of a line of text for purposes of line justification. Characteristics - Definitions: Values - Definitions Inherit Toggle Language IDREF Hyphenation - Disallowed (0) or allowed (1). Toggle Hyphenation Zone - Specifies the amount Size/Distance of space from the margin that can be left by choosing not to hyphenate (aesthetic rag). EXPLANATION: a. The Hyphenation Zone only has an effect for Quadding Quad values of right, left, in, and out. In these cases, the zone amount gives the maximum distance from the ragged margin that the text should be set. The effect of this characteristic is independent of the setting of the Hyphenation characteristic. 40.3.4 Wordspace. The white space between words that may be adjusted for readability and line justification. Characteristics - Definitions: Values - Definitions: Inherit Toggle Minimum - The least amount of space Size/Distance that can appear. Nominal - The preferred amount of Size/Distance space (what should appear). Maximum - The greatest amount of Size/Distance space that can appear. EXPLANATION: a. The effect of specifying different values for Minimum, Nominal, and Maximum allows for variable spacing to be used for horizontal justification. b. When the values for Minimum, Nominal, and Maximum are equal, the spacing is fixed (not variable). c. Only positive values shall be specified, typically with em spaces. 40.3.5 Letterspace. White space between letters in a word which may be adjusted for readability and line justification. Characteristics - Definitions: Values - Definitions: Inherit Toggle Minimum - The least amount of Size/Distance space that can appear. Nominal - The preferred amount Size/Distance of space (what should appear). Maximum - The greatest amount of Size/Distance space that can appear. Kerntype - allowed types of kerning. List ( None, Pair, Track, Sector, PairTrk, TrkSectr ) Kerning Pairs - specification of Pointer table of kerning pairs. EXPLANATION: a. The effect of specifying different values for Minimum, Nominal, and Maximum allows for variable spacing to be used for horizontal justification. b. When the values for Minimum, Nominal, and Maximum are equal, the spacing is fixed (not variable). c. The Size/Distance values shall have positive values, typically em spaces. d. Kerntype specifies the method of kerning to be used by the composition system. Pair kerning specifies an approach whereby kerning pairs are looked up in a kerning table. Track kerning is a methodology for placing the same amount of space between characters in a line. Sector kerning is an algorithmic approach for placing space between characters depending on the characters in the line. Combinations of pair and track kerning and track and sector kerning may be specified. 40.3.6 Indent. Positioning along the writing direction. Characteristics - Definitions: Values - Definitions: Inherit Toggle Left Indent - Placement of a Size/Distance text margin relative to the left boundary of the current Layout Area. Right Indent - Placement of a Size/Distance text margin relative to the right boundary of the current Layout Area. First Line - Special left Size/Distance Indent value for first line of content. EXPLANATION: a. For Left and First Line Indents, a positive value positions the text margin the specified distance to the right, and is the default. A negative value specifies an indent to the left. b. For a Right Indent, a positive value positions the text margin to the left and is the default. A negative value specifies an indent to the right. c. The syntax for indents allows for specification in two ways: 1. With respect to the boundary of the current Layout Area, i.e. "+2pi" or "-2pi". A Size/Distance value appearing alone specifies a distance from the margin of the current Layout Area. For a left indent specification, a "+" indicates an indent to the right and a "-" indicates an indent to the left (a "hanging indent"). For a right indent specification, a "+" indicates an indent to the left and a "-" indicates an indent to the right. If no "+" or "-" appear, a "+" is assumed. 2. With respect to the text margin determined by the parent element's indent, i.e. "@+2pi" or "@-2pi". The delimiter "@" can be used to specify that the indent is relative to the text margin established by the element's parent, including any indenting that may have been applied. For example, if a para element were indented two picas from the left margin of the Layout Area and the specification for its child warning is "@+2pi", the warning will be indented 2 picas from its parent, or 4 picas from the left margin of the current Layout Area. With regard to inheritance, the "@" is expanded for the e-i-c instance where it is specified, and what is inheritable is the resulting value. For example, if the current left margin is 5 picas and an element's indent specification includes leftind="@+2pi" then this element's left margin will be 7 picas. If this element's child's indent specification is <indent inherit="1">, then the child should inherit the parent's indent, therefore having an indent of 7 picas, rather than inherit the parent's indent specification of "@+2pi" (where now the "@" refers to the parent's 7 pica indent), which would give it a 9 pica indent. d. The syntax for First Line permits a "*" to be used as the first character of the First Line value to refer to the value that the Left Indent has for this e-i-c instance. That is, to get the effect of having a First Line indent equal to the Left Indent, (which would give a "block indented" paragraph where all lines have the same left indent) one would set firstln="*". Note that to specify a non-zero First Line indent that is relative to the Left Indent, the value of First Line might be "*+15pi". When the Left Indent is specified and the First Line indent is not, the value for First Line indent is determined by defaulting and inheritance rules. If this value is "*", it is replaced with the value of Left Indent of the current e-i-c. e. The delimiter "*" can be used as the first character of the Right Indent value to specify that the Right Indent is to be relative to the Left Indent rather than relative to the right boundary of the text area (and that a positive offset will be to the right of the Left Indent). This allows the Right Indent to be specified in terms of the Left Indent and the width of the block of text. For example, in a layout area of 45 picas, a Left Indent specification of "2pi" and a Right Indent specification of "*+18pi" would produce text with a 2 pica left indent and a 25 pica right indent (and in a layout area of 30 picas, the same specification would produce text with the same width even though the right indent would now be only 10 picas). f. If the "@" or "*" syntax is used in the docdesc or a named environment, the (unexpanded) indent specification itself would be expanded at the time the environment is referenced by a given e-i-c. This way, for example, if one specifies a relative First Line indent of "*+10pt" in the docdesc, all paragraphs would, by default, have a 10pt indent regardless of the particular Left Indent of the paragraph. Once an e-i-c's indent is determined from an environment as discussed in the previous sentence, the "@" or "*" has been expanded and is gone; if an offspring of this e-i-c inherited its indent, it would inherit the resolved indent values of its parent. g. Indent specifications are ignored unless a new line is triggered by a startln="1" or by an endln="1". h. The firstln indent is used only once per element. If the element's #PCDATA is interrupted by an element with startln="1" or endln="1" or a puttext, usetext, or putgraph that start or end a line, the remaining character content uses the original left indent specification for its first and subsequent lines. The intervening element with a startln="1" or endln="1" uses its own specifications for all of its content. 40.3.7 Horizontal quadding. The horizontal alignment of text lines within an element with respect to the Layout Area boundaries. Characteristics - Definitions: Values - Definitions: Inherit Toggle Horizontal Quadding List (Right - Flush right/ragged left. Left - Flush left/ragged right. Center - Centered. In - Flush to inside margin/outside ragged. Out - Flush to outside margin/inside ragged. Justify - Flush left & flush right. As is - Place lines exactly as in the source.) Lastline - How to align the List (Right - Flush right/ragged left. Left -Flush left/ragged last text line of the element. right. Center - Centered. In - Flush to inside margin/outside ragged. Out - Flush to outside margin/inside ragged. Justify - Flush left & flush right. Relative - see note c.) EXPLANATION: a. In and Out quadding values refer to the bind edge and the edge opposite the bind edge, respectively. (See 60.7 for more information on the bind edge.) b. The "asis" value specifies that space characters and line breaks within the text be preserved and no additional space characters or line breaks be added. It is intended to be used in conjunction with monospace fonts. c. When a value for Lastline is "relative", the Lastline is aligned according to the value of Quadding, except when Quadding is "justify" in which case Lastline is aligned "left". d. Quadding specifications are ignored unless a new line is triggered by a startln="1" or by an endln="1." In mixed content models where the child's content is not separated from the parent's content by a startln or endln, the parent's quadding specifications are used. e. If an element's character content is interrupted by an element with a startln="1" or endln="1" or a puttext, usetext, or putgraph that start or end a line, the last line of #PCDATA prior to the intervening output uses the lastquad of the quadding specification. f. When a sequence of elements without a startln="1" or endln="1" occurs, the indent specifications of the first element are used for the character content of all subsequent elements. g. When an element's character content content is interrupted by other elements with a startln="1" or endln="1" (mixed content models), the left indent specification is used for all remaining lines of the element's character content. The firstln indent is used only once per element. 40.3.8 Highlight. Special presentation characteristics for text. Characteristics - Definitions: Values - Definitions: Inherit Toggle Foreground/Background - Reverse color Toggle Scoring - Overlay rules on the text line. Integer Score Weight - Weight of the rule. Size Score Offset - Offset of the base of the Size rule to the text baseline. Score Character - Character to be overlaid String on the text. Background Color - Color of the area between List (BBlack, BWhite, BRed, BOrange, text baselines. BYellow, BGreen, BBlue, BViolet, BBrown, BGray) Foreground Color - Color of the text List (Black, White, Red, Orange, Yellow, Green characters Blue, Violet, Brown, Gray ) Background Screen - Shading of the area Integer between text baselines. Foreground Screen - Shading of the Integer text characters All Caps Toggle Score Spaces - Whether spaces should be Toggle scored/overlaid EXPLANATION: a. The Scoring, Score Weight, and Score Offset characteristics are used together to create rules overlaid with the text, for example underlines and overlines. To achieve score offset, a positive value will place the score below the baseline, and a negative value will place the score above the baseline. The Score Character may additionally be specified to overlay a different character on the text, for example an "x" for a "strike out" effect. b. The integer value for Foreground and Background Screen is specified as a percentage. For example a value of "80" means 80% of black. c. The value of scoring indicates the multiplicity of the score rule. Therefore, a value of zero means there is no scoring (and the Score Weight and Score Offset are ignored); a value of one means to score with a single rule (whose weight and offset are determined by Score Weight and Score Offset); a value of two means to score with a double rule (where each individual rule's weight is given by Score Weight, Score Offset measures the offset to the base of the lower of the two rules, and the gap between the two rules is left to be resolved by the output system). d. If the Score Spaces toggle is "off", spaces (blanks) in the highlighted text are not overlaid with a rule or score character. If the Score Spaces toggle is "on", spaces should be scored. 40.3.9 Change mark. The data that appears in the Change Mark Area, triggered by the occurrence of a particular element. Characteristics - Definitions: Values - Definitions: Literal - A literal that should String appear instead of a bar. Bar Thickness - The thickness of Size/Distance the Change Bar. Join - Join bars of contiguous Toggle lines of marked text. Type - Whether this element starts List (Content, Start, End) ends, or contains the region to be marked. EXPLANATION: a. Either a bar thickness of greater than zero or a literal should be specified. If both are specified, the bar should appear and not the literal. b. The bar is positioned in the Change Mark Area with its bottom aligned to the baseline of the text to which it corresponds. The height of the bar equals the leading specified for the element. The Bar Thickness indicates the width of the bar. c. A literal is positioned in the Change Mark Area with its baseline aligned to the baseline of the text to which it corresponds. The total width of the literal should be less than that of the Change Mark Area (that is, the literal is expected to fit on one line). d. When Join is turned on, bars of adjacent lines of text, even though they may be separated by some space in addition to the leading, should be extended so that they join to form one contiguous bar. e. The Type characteristic indicates whether this e-i-c starts, ends, or contains the region to be marked with the specified change mark. If Type is Content, then the change mark is in effect for the duration of the current element. If Type is Start, then the change mark goes into effect at the beginning of the current element and stays into effect until the end of an element whose Change Mark Type is End. (Change Mark Types of Start and End allow the use of individual empty elements for the delineation of change regions.) f. When a change mark is specified for an e-i-c and the Type characteristic is Content, the change mark continues for the duration of the element including all its children. When a change mark is specified for an e-i-c and the Type characteristic is Start, the change mark continues until an e-i-c with a Change Mark Type equal to End is encountered; the change mark continues for all parts of all elements and their children between the start and end point. g. When any children of a region that has a Change Mark in effect float, they will continue to be marked by the change mark. 40.3.10 Prespace. The amount of space in the vertical direction added before an element (in addition to its leading). Characteristics - Definitions: Values - Definitions: Minimum - The least amount of Size/Distance space that can appear. Nominal - The preferred amount of Size/Distance space (what should appear). Maximum - The greatest amount of Size/Distance space that can appear. Conditional - Indicates whether List (Keep, Discard) to keep or discard space at a column or page break. Adjacency Priority - Indicates a List (Force, Medium, Low, None) preference for choosing one element's spacing requirements over another's. EXPLANATION: a. The effect of specifying different values for Minimum, Nominal, and Maximum allows for variable spacing to be used for vertical justification. b. When the values for Minimum, Nominal, and Maximum are equal, the spacing is fixed (not variable). c. Prespace and Postspace values are not normally additive. Whether to use an element's Prespace or the preceding element's Postspace as the spacing between two elements is determined by the Adjacency Priority value. The value from the element with the highest Adjacency Priority is used. When the Adjacency Priority values are equal, the element with the larger Nominal value is used. If the Adjacency Priority values are equal and the Nominal values are equal, the given Nominal value, the maximum of the Minimum values, and the minimum of the Maximum values will be used for the effective spacing's Nominal, Minimum, and Maximum values respectively. When the Adjacency Priority values both equal "Force", the effective spacing's Nominal, Minimum, and Maximum values will each be the sum of the respective Nominal, Minimum, and Maximum value pairs. d. Either through defaulting or by explicit specification, an e-i-c may have either a significant prespace and startln="0" or a significant postspace and endln="0". For example, an e-i-c instance with startln="0" might be expected to contribute its prespace depending on whether a subsequent e-i-c instance has startln="1". Therefore, pre/postspaces (and their adjacency priorities) of all e-i-c instances that occur since the last typeset material (whether from content text or generated material) up to the next typeset material must be compared to determine what value would be used; then, vertical spacing of this amount is actually used if and only if any of the intervening e-i-c instances had specified a new line via startln="1" or endln="1" (either explicitly or via defaulting). e. The priority characteristic is used to determine which element's characteristics and values take precedence when there is a conflict. The priority characteristic range of values in descending order is: "Force", "High", "Medium", "Low", and "None". Normally a simple comparison of these values will provide a solution to the conflict. Where priority characteristic values are equal, there are additional precedence rules that are applied depending on where the characteristic is encountered. 40.3.11 Postspace. The amount of space in the vertical direction added at the completion of an element (in addition to its leading). Characteristics - Definitions: Values - Definitions: Minimum - The least amount of Size/Distance space that can appear. Nominal - The preferred amount Size/Distance of space (what should appear). Maximum - The greatest amount of Size/Distance space that can appear. Conditional - Indicates whether List (Keep, Discard) to keep or discard space at a column or page break. Adjacency Priority - Indicates a List (Force, High, preference for choosing one Medium, Low, None) element's spacing requirements over another's. EXPLANATION: a. The effect of specifying different values for Minimum, Nominal, and Maximum allows for variable spacing to be used for vertical justification. b. When the values for Minimum, Nominal, and Maximum are equal, the spacing is fixed (not variable). c. Prespace and Postspace values are not normally additive. Whether to use an element's Prespace or the preceding element's Postspace as the spacing between two elements is determined by the Adjacency Priority value. The value from the element with the highest Adjacency Priority is used. When the Adjacency Priority values are equal, the element with the larger Nominal value is used. If the Adjacency Priority values are equal and the Nominal values are equal, the given Nominal value, the maximum of the Minimum values, and the minimum of the Maximum values will be used for the effective spacing's Nominal, Minimum, and Maximum values respectively. When the Adjacency Priority values both equal "Force", the effective spacing's Nominal, Minimum, and Maximum values will each be the sum of the respective Nominal, Minimum, and Maximum value pairs. d. Either through defaulting or by explicit specification, an e-i-c may have either a significant prespace and startln="0" or a significant postspace and endln="0". For example, an e-i-c instance with startln="0" might be expected to contribute its prespace depending on whether a subsequent e-i-c instance has startln="1". Therefore, pre/postspaces (and their adjacency priorities) of all e-i-c instances that occur since the last typeset material (whether from content text or generated material) up to the next typeset material must be compared to determine what value would be used; then, vertical spacing of this amount is actually used if and only if any of the intervening e-i-c instances had specified a new line via startln="1" or endln="1" (either explicitly or via defaulting). e. When an unconditional page break is specified (using Textbreak's Start Page characteristic), the page preceding the page break is usually filled at the bottom with white space. However, when the Conditional characteristic of the Postspace that is actually used (according to note c) just previous to the page break is "Keep", the requested Postspace should be used at the bottom of the page preceding the break without any additional fill. For example, if immediately preceding a page break one specifies a Postspace with an Adjacency Priority of "Force" a Nominal of 0, and a Conditional of "Keep", the last piece of text on the page preceding the break will be placed at the bottom of the page, and the rest of the page contents will be "spread out" evenly using the vertical justification flexibility provided by the various composition parameters (i.e., all the Pre- and Postspace on the page will tend toward its Maximum values so as to fill the page). f. The priority characteristic is used to determine which element's characteristics and values take precedence when there is a conflict. The priority characteristic range of values in descending order is: "Force", "High", "Medium", "Low", and "None". Normally a simple comparison of these values will provide a solution to the conflict. Where priority characteristic values are equal, there are additional precedence rules that are applied depending on where the characteristic is encountered. 40.3.12 Keeps. Conditions for controlling or disallowing the breaking of elements over column or page boundaries. Characteristics - Definitions: Values - Definitions: Inherit Toggle Keep - Keep the whole element Toggle content together within the column, page, or line boundary. Scope - The scope in which to List (Column, Page, Line) keep the element together. Widow Count - The number of lines Integer to keep at the top of a column. Orphan Count - The number of lines Integer to keep at the bottom of a column. Keep Next - Keep with next element. Toggle Keep Previous - Keep with previous Toggle element Keep Floats Out - Specifies what IDREFS category of floats should not be permitted to interrupt the pagination of the current element. EXPLANATION: a. Keep conditions can be nested (treated like a stack). A Column Keep = Off condition of a child does not override a Column Keep = On of a parent. That is, On always takes priority. The ending of a nested Keep does not turn off a parent's Keep. (Parent and child Widow Count and Orphan Count interact as any other characteristics rather than in this special pre-emptive manner.) b. The Scope indicates the boundaries across which the element cannot break, either the column boundary, page boundary, or line boundary. Specifying "column" implies also keeping within the page. A Scope value of Line implies the output system should inhibit line breaks within the element if feasible; how feasibility is determined and what happens when infeasible is left to be determined by the output system. c. In the event that element content must break across a column boundary, the Widow Count and Orphan Count specify the minimum number of lines that must remain at the top and bottom of the column, respectively. d. The "next" element is the element (or part of an element) that next contributes content to the same Layout Area (Flowing Text Area or Footnote Area) in the output stream (whether this content is due to character content directly from the source or via the action of a Usetext, Puttext, Putgraph, Character Fill, etc.). Note that one or more ancestors of the current element may end and one or more elements may begin (and maybe end) before more content is contributed to the output stream; nevertheless, an indication of Keep Next on the current element would imply that a break cannot occur between the last contributed content of the current element and the next contributed content in the same Layout Area of the output stream. Note that when an element's character content is interrupted by other elements (mixed content models), Keep Next applies to the last character content of the element's character content. e. The "previous" element is the element (or part of an element) that last contributed content to the same Layout Area (Flowing Text Area or Footnote Area) in the output stream (whether this content was due to character content directly from the source or via the action of a Usetext, Puttext, Putgraph, Character Fill, etc.). Note that one or more ancestors of the previous element may end and one or more elements may begin (and maybe end) before the start of the current element without more content getting contributed to the same Layout Area of the output stream; nevertheless, an indication of Keep Previous on the current element would imply that a break cannot occur between the last contributed content in the output stream and the first contributed content put into the same Layout Area of the output stream by the current element. f. Keep Next/Previous indicates that a break cannot occur immediately following/preceding the element's content (between this element and the next/previous element). For Scope of Column, this means that neither a column or page break may occur between the current element and the next/previous one; for Scope of Page, a page break may not occur between the current element and the next/previous one; for Scope of Line, a line break may not occur between the current element and the next/previous one. Note that, unless the Keep characteristic itself is enabled, enabling Next or Previous, while preventing a break between the current element and the next/previous one, does not prevent a break within the current element itself. g. See the Vertical Justification characteristic for information on how Keep Characteristics interact with other characteristics that affect vertical justification. h. The Keep Floats Out characteristic's value is a list of ID references to Float Location Ids. All pending floats associated with a Float Location whose ID is included in the Keep Floats Out characteristic will remain pending (i.e., will not be permitted to be placed into the output stream) for the duration of the current element and all its children. This allows, for example, for one to disallow floating graphics from interrupting the pagination of a multipage table. Whether the floating graphic gets placed into the output stream before or after the table--and exactly where it gets placed--depends on the complete set of floating constraints. Note that floats with non-flexible page types such as same, next, facing, and frontback can easily provide constraints that, in combination with the Keep Floats Out characteristic use, are impossible to satisfy. Note also that there is no implicit interaction with the Span category and the Keep Floats Out characteristic; unless the Keep Floats Out characteristic is used to inhibit certain floats for the duration of a spanned element, it is possible for floats to interrupt the pagination of a spanned element. In this case, when the floated element is column wide and the span creates a different number of columns, it is possible that the set of floating constraints will not be satisfiable or that the result may not be what the user expects. i. When a sequence of elements without a startln="1" or endln="1" occurs and scope="col" or scope="page", the keep specifications for the first element are used for all subsequent elements in the sequence. j. When an element's character content content is interrupted by other elements with a startln="1" or endln="1" (mixed content models), the widow and orphan conditions are used for each character content segment. 40.3.13 Vertical justification. The priority information for each characteristic necessary for making decisions for purposes of vertical justification. Characteristics - Definitions: Values - Definitions: Inherit Toggle Prespace Priority List (Force, High, Medium, Low, None) Postspace Priority List (Force, High, Medium, Low, None) Keep Priority List (Force, High, Medium, Low, None) EXPLANATION: a. Where it is not possible to honor all elements' Prespace, Postspace, and Keep characteristic values for the purposes of vertical justification on a column or page, a comparison of the priority characteristics listed above determines which characteristics shall prevail. Where Priority values are equal, the order of occurrence shall be used to determine priority, with the preceding elements taking precedence. 40.3.14 Textbreak. Characteristics for allowing controlled interruptions of normal text flow. Characteristics - Definitions: Values - Definitions: Start Column - Start at beginning Toggle of new column. Start Page - Start at the List (Off, Verso, Recto, Next, Verso with blank front, beginning of a new page. Recto with blank back) Page Model ID - The Page Model IDREF to use when starting the page New Page Model - Use the new List (None, Global, Local) page model. Start Line - Start at beginning Toggle of a new line. End Line - At the end of the Toggle current element, prepare to start on a new line. EXPLANATION: a. Start Column, Start Page, End Line, and Start Line do not cause vertical spacing, but imply a logical start beginning a new column, page, or line respectively. That is, they work in conjunction with other text positioning characteristics, such as leading and prespace, to indicate that the next text to be placed begins at the new column, page, or line, but do not indicate any additional leading or spacing. 1. If the current element has endln="1" and the next element has startln="1", then prespace and postspace are used as determined by the values described in the description of prespace and postspace and the leading of the next element is used between the last line of the current element and the first line of the next element. 2. If the current element has endln="1" and the next element has startln="0", then prespace and postspace are used as determined by the values described in the description of prespace and postspace and the leading of the next element is used between the last line of the current element and the first line of the next element. 3. If the current element has endln="0" and the next element has startln="0", then no prespace or postspace is used. If the Force Leading toggle is enabled, the leading for each line will be equal to the largest leading set on an element on that line. If the Force Leading is not enabled, the leading will be equal to the first leading set until a new line is specified (via startln="1" or endln="1"), and the output system will use whatever leading is required to avoid overprinting of text. 4. If the current element has endln="0" and the next element has startln="1", then prespace and postspace are used as determined by the values described in the description of prespace and postspace and the leading of the next element is used between the last line of the current element and the first line of the next element, b. When Start Column is enabled, the "next" column is the column to the right of the current column, or, if the current column is the right most column, the leftmost column on the next page. c. Start page has the following options: 1. When start page is equal to recto, the recto page model of the appropriate triple will be used. If this specification causes the previous verso to be blank then the last formatted recto page will be reformatted on the recto with a blank verso page model of the current triple. 2. When start page is equal to verso, the verso page model of the appropriate triple will be used. If this specification causes the previous recto to be blank then the last formatted verso page will be reformatted on the verso with a blank recto page model of the current triple. 3. When start page is equal to recto with blank back, the recto with blank back model of the appropriate pageset will be used if available. Note that the blank back will use the blank page model of the appropriate page set if available. 4. When start page is equal to verso with blank front, the verso with blank front model for the appropriate pageset will be used if available. Note that the blank front will use the blank page model of the appropriate page set if available. d. When the Start Page characteristic is enabled, the Start Column and Start Line characteristic values are automatically enabled. When the Start Column characteristic is enabled, the Start Line characteristic value is automatically enabled. e. A value specified for the Page Model ID is meaningful only when the New Page Model characteristic is set to global or local and the Start Page characteristic is enabled. The New Page Model value of Global means that the page model specified by the Page Model ID will become the current page model and will remain in effect until another Textbreak category use. The new Page Model value of Local means that the page model specified by the Page Model ID will become the current page model until the processing of the current element is completed, a new page is started when processing of the element is completed, the Page Model previously in effect becomes the current Page Model. f. Setting End Line on an element causes a new line to be started before the first text that follows the current element's end is placed, whether what immediately follows the current element's end is text or another element. 40.3.15 Span. Positioning of an element across all columns on a page. Characteristics - Definitions: Values - Definitions: Span - Specifies the number of columns Integer into which to format the Flowtext. EXPLANATION: a. If the Span characteristic is zero, the Span category has no effect; whatever spanning (or lack thereof) currently in effect continues. If the Span characteristic is a positive integer, it specifies the number of columns into which to format the Flowtext (using the Flowing Text Area specification in the current page specification whose Number of Columns specification matches the number of columns specified by this Span characteristic). That is, all text currently on the page is balanced over the current number of columns; then, the entire Flowing Text Area is "spanned" and then redivided into the number of columns specified by the Span characteristic. Therefore, if span="1", the behavior is to span the entire page with one column. The effect of the span is scoped by the element that spans; when that element ends, the effect of returning to the parent element is the same as starting a new spanned area with a Span characteristic value equal to that of the parent. b. There are no cases where some, but not all, Column Areas may be spanned (though the spanned area may be redivided into more than one column). c. If a non-zero value of Span is specified for an element, the Textbreak's Start Line characteristic is treated as if it were set to "on". 40.3.16 Border. The pattern that appears along page boundaries, triggered by the occurrence of a particular element. Characteristics - Definitions: Values - Definitions: Border Name - Name of the border String EXPLANATION: a. The Border Name must be a Border Indicator defined in the Border Specification for the page on which the element falls. The graphic referenced by the Border Entity associated with the Border Indicator appears on the page. b. The border graphic will overlay the page. c. When a border is specified for an e-i-c, the border begins on the page where that element starts. The border repeats on each page during the duration of that element (including children) up to and including the page where the element is ended. d. When more than one border is referenced on a page, it is up to the output system to determine which border appears. 40.3.17 Float. This category indicates that an element will not be paginated in input document order but will instead float to some other location in the output instance where that location will be determined by the output system according to a specified set of constraints. Characteristics - Definitions Values - Definitions Float location ID reference IDREF Width - the width to which to List (Page, Column) compose the floated material Scope - the ancestral element(s) Name(s) of element(s) that scope the current float Page Type - the page(s), relative List (Same, Facing, Front/Back, Next, to the current page, to which this Forward, After Reference, Inline) material should float Multi-reference Name - an identifier NMTOKEN to distinguish this multi-reference float EXPLANATION: a. Specifying float characteristics in a charlist indicates that the contents of the associated e-i-c, as well as any material generated by ruling, puttext, putgraph, or usetext, appears in the float layout area specified by the Float location ID reference. b. The Width characteristic value (page or column wide) indicates the width to which the material to be floated is composed. The value that is used is the page or column width that is current at the time the floating e-i-c instance is encountered in the input. It is possible to specify a composition width for a floating element that is wider than the float location area into which it is destined--as with all other float constraint problems, the output system may issue an error or may employ some other fallback resolution algorithm. c. The Scope characteristic specifies the element(s) that delimit the range for this float. Scope uses the same mechanism as "attloc"; that is, each element named in the Scope characteristic refers to an ancestor of the position of the current e-i-c in the input document. When the element named by Scope terminates (i.e., when its end tag is encountered), the Scope ends. Note that Scope gives a list of element names--the first ancestral end tag encountered terminates the scope. If unspecified for a given float, the scope is the entire document. d. When the end of any scoping element is reached, all floats scoped by that element are "flushed" (in the same sense as when a Float location ID is specified in a Reset Control list). For Float Type of Once and Multi-Reference, flushing means the floats are forced out into the output stream following any material the current e-i-c would supply to the output stream (but preceding any savetext, usetext, puttext, ruling, putgraph with placement equals after) even if this would violate the floating constraints. (This allows, for example, for containing floating within chapters.) For Float Type of Repeat at Page Break, the float locations are emptied without contributing anything further to the output stream. e. Floating an element into a Float location whose Float Type is set to Repeat at Page Break causes the contents of the e-i-c to occur in the specified float layout area each time the float's scoping element breaks across a page. (The specified float layout area must be allowed on the page.) On the page the scoped element starts, only bottom float layout areas are filled. On the page the scoped element ends, only top layout areas are filled. On pages spanned by the scoped element, both top and bottom float layout areas are filled. f. In float, the Page Type characteristic specifies on which page the specified float layout area can occur. Values for this characteristic are relative to the location where the e-i-c occurred in the source document (its reference). Possible specifications are Same (same page as the reference), Facing (page facing the page on which the reference occurred), Front/Back (opposite side of same sheet as the reference), Next (the page following that on which the reference occurred), Forward (the next available page including anywhere on the same page as the reference), After Reference (the next available page including on the same page as the reference provided the float would end up after its reference), Inline (see following note). In case of floating multipage elements, the Page Type specifies the type of first page on which the float will appear. g. A float Page Type of Inline means that the element should be placed, if possible, into the output stream at the point of its reference--that is, it should not float. However, if it is not possible to place the material inline given all the operative constraints, then the element should be floated as if its Page Type were specified as After Reference (and the rest of the characteristics in the float category are as specified). The two major constraints that determine whether the material is placed inline or floated are (1) given that the element may be unbreakable (as indicated by the Keeps category) or may at least have an initial region that is not breakable over a page break, whether it can fit inline on the page without violating the page layout flexibility allowed by the Keeps, Prespace, Postspace, and Vertical Justification Information categories; and (2) given that all floats associated with the same Float location as this element must be placed into the output stream in first-in-first-out order, whether placing this element inline will violate this order (in practice, this generally means that if an element associated with the same float location is currently pending, then this element may not be placed inline). h. It is possible for Page Type specifications to create sets of constraints that cannot be resolved. For example, specifying Page Type of Same for more than one float per page can, depending on their sizes and other constraints, easily create an unresolvable situation. Also, having a float with Page Type of Next followed by a float of Page Type of Same will make it impossible to maintain the order of the floats. In such cases, the output system may either issue an error message or attempt resolution that does not satisfy all the constraints. The FOSI writer should avoid writing specifications that lead to such over-constrained situations. i. This Output Specification says nothing about the details of how Page Types of Facing or Front/Back work. In particular, it does not describe how the output system should handle the case that a specification of Facing or Front/Back requires that material gets floated "backward" onto a previous page. FOSI writers should realize that Page Type specifications of Facing or Front/Back may not be supported by all output systems or may have system dependent results with very different appearances. j. If the float is associated with a Float location whose Float Type is Multi-reference, the float appears exactly once per page for any page from which this float was referenced one or more times. To be able to determine when two references are for the same multi-reference float, each reference to a multi-reference float must have an identifying name. For each float associated with a Float location whose Float Type is Multi-reference, the floating e-i-c instance's Float category's Multi-reference Name characteristic must specify an identifier that identifies this multi-reference float. (All multi-reference floats for which no Multi-reference Name is given are considered to be equivalent; i.e., they are all treated as if they were given the same name.) The scope of the Multi-reference names is the same as the Scope of the multi-reference floats. Within the entire scope of a given multi-reference float, the content (the material being floated) is taken from the first reference using a given Multi-reference Name, and this content is used (and any given content is ignored) for all other references throughout the scope of that multi-reference float. k. Within the current element's characteristic list, the Textbreak category's characteristics of startln and endln are both treated as if they were set on ("1"). Startcol has no meaning and is ignored. The characteristics startpg, newpgmdl, and pageid are relevant for the floating material (but have no effect on the material that does not float) as follows: if startpg is not off and newpgmdl=local, then the floating element begins on a new page and the pageset specified by the pageid is used for the duration of the floating element's content. This allows, for example, the floating of an element into a series of landscape pages. (A value of newpgmdl=global is treated as if newpgmdl=local when the e-i-c instance in question floats.) l. Between individual floats within a single float location, the pre-/postspace specified in each floated element combines in the usual way with the pre-/postspace of adjacent floats. 40.3.18 Alignment Group. Allows for placing potentially multi-line elements horizontally next to each other in the output data stream. Characteristics - Definitions: Values - Definitions: Reference point - Vertical alignment point List (Top, First, Last, Bottom, Middle) Postspace - space under wrapped elements Toggle EXPLANATION: a. When included in a charlist, algroup determines the relative position of the output element that follows the element specifying the algroup category provided that the margins and indents of the two elements are specified in such a way as to avoid overprinting. Alignment does not occur if the margins and indents are such that overprinting of text would occur (but see also note c below). Note that more than two elements can be aligned horizontally using algroup on all of the elements (with the possible exception of the last one to be aligned). b. The options for reference point are: top, first, last, bottom, and middle. Top refers to the ascender, cap-height, or font height of the first line (the precise determination of which depends on the font and may be system dependent), first refers to the baseline of the first line, last to the baseline of the last line, and bottom to the descender of the last line (which is again font and/or system dependent). For example, by setting the reference point of two adjacent paragraph-like structures to first, they will appear side-by-side aligned at their initial baselines. Middle implies that the reference point will be the vertical center of the lines of material. While an individual implementation of "vertical center" is system dependent, it is recommended that, as far as practical, this be defined as midway between the "first" and "last" reference points. The reference point of the element following that with the algroup specification is treated as (1) "top" if the preceding element with the algroup specification has a reference point of "top" and (2) "first" otherwise. c. If the first of two structures uses the Alignment Group category but the left margin (as determined by its Left Indent) of the second structure (which does not have an Alignment Group category specification) is not large enough to allow for the width of the first structure (as determined by that structure's Right Indent), then no horizontal alignment will take place (and the two structures would be positioned as if the Alignment Group category had not been specified). However, if the second structure's First Line indent is large enough to allow for the width of the first structure, then horizontal alignment will take place (regardless of the non-first line left margin of the second structure) and, in fact, the second structure will use the value of its First Line indent for its left margin for as many lines as necessary to clear the first structure at which point the second structure's left margin will then revert to the value as specified by its Left Indent. This allows for some simple automatic wrapping of the right hand structure's text around the left hand structure. d. An element without an algroup specification can be part of an alignment group only if (1) the element immediately preceding it has an algroup specification and (2) its margins and indents are such as to avoid overprinting with the preceding element. The first element following an alignment group that is not part of the alignment group is positioned below the alignment group using its margins and indents as usual in the case when no aligning is involved. e. The vertical spacing between the aligned set of elements and the preceding element is determined by: (1) calculating the vertical spacing that would normally result between the preceding element and the first element of the horizontally aligned group without consideration of the algroup and then (2) applying this vertical spacing between the preceding element and that element of the aligned group whose vertical extent most extends back toward the preceding element when all aligned elements are aligned as specified. f. The vertical spacing between the aligned set of elements and the following element is determined by: (1) calculating the vertical spacing that would normally result between the last element of the horizontally aligned group and the following element without consideration of the algroup and then (2) applying this vertical spacing between the following element and, regardless of wrapping, that element of the aligned group whose vertical extent most extends forward toward the following element. g. When the postspace toggle is set "on", the postspace, as provided in the charlist for the element, is applied before the adjacent group element can wrap underneath. When the toggle is set "off", no postspace is applied to the element before wrapping of the adjacent element occurs. 40.3.19 Suppress. Suppressing text from the output data stream. Characteristics - Definitions: Values - Definitions: Suppress Toggle Suppress Children Toggle EXPLANATION: a. When both Suppress and Suppress Children are turned on, the entire content of the element (including any children it may have) should not appear in the output stream, regardless of whether or not Suppress is turned on for those children. b. When Suppress is turned on but Suppress Children is not, the text characters of the element should not appear in the output stream, but the processing of children elements is not affected. c. When Suppress Children is turned on but Suppress is not, the text characters of the element are processed as usual, but the children elements are not processed. 40.3.20 Boxing. The drawing of a box. Characteristics - Definitions: Values - Definitions: Top Offset Size/Distance Bottom Offset Size/Distance Left Offset Size/Distance Right Offset Size/Distance Top Offset Origin - The method for List (Top, First) determining the zero position for Top Offset. Bottom Offset Origin - The method List (Last, Bottom) for determining the zero position for Bottom Offset. Side Offset Origin - The method for List (Text, Column, Content) determining the zero position for Side Offset. Left Gap - Additional space between Size/Distance boxed material and box's left side. Right Gap - Additional space between Size/Distance boxed material and box's right side. Thickness Size/Distance Top Rule Type List (TBlank, TSingle, TBold, TDouble, TBlank, TDot, TDash) Bottom Rule Type List (BBlank, BSingle, BBold, BDouble, BBlank, BDot, BDash) Left Rule Type List (LBlank, LSingle, LBold, LDouble, LBlank, LDot, LDash) Right Rule Type List (RBlank, RSingle, RBold, RDouble, RBlank, RDot, RDash) Outline Color - Color of the List (Black, White, Red, Orange, Yellow, Green, outline rules. Blue, Violet, Brown, Gray) Outline Screen - Shading of the Integer outline rules. Interior Color - Color of the area List (IBlack, IWhite, IRed, IOrange, IYellow, IGreen, Blue, within the outline rules IViolet, IBrown, IGray) Interior Screen - Shading of the Integer area within the outline rules. EXPLANATION: a. The integer value for Outline and Interior Screen is specified as a percentage. For example a value of "80" means 80% of black. b. The offsets determine how far away from the boxed content area the rules will be drawn (positive values always mean "away" from the content). c. Note that boxing causes the boxed material to become an unbreakable unit (the entire region will behave as if keep were enabled for it); therefore a boxed region will not break over columns. The boxing category is also permitted in subchars; that is, a box can be put around material generated by a Puttext or Usetext. d. If startln="1" is in effect for the text being boxed, siderel of "text" means the width of the boxed content area is considered to be the full width to the margins currently in effect; siderel of "col" means the width of the boxed content area is considered to be the full width of the current column (regardless of margins); siderel of "content" means the width of the boxed content area is considered to be the width taken by the widest extent of text or ruling within the boxed content. When startln="1" is in effect, the leftgap and rightgap characteristics are ignored. e. If startln="1" is not in effect for the text being boxed, siderel is treated as equal to content and the box surrounds the in-line text. Note that the boxed text is unbreakable (i.e., cannot break over lines) and must therefore fit on one line in the output. When startln="1" is not in effect, the leftgap and rightgap characteristics give an amount of space to add (inside the box) preceding and following the actual content being boxed. (Values of zero would mean the left and right rule would touch the boxed text; positive values are, in both cases, "away" from the text.) f. A "bold" rule is a rule whose thickness is twice that of a single rule. A "double" rule is composed of two rules separated by a gap; the overall thickness of the double rule is equal to a bold rule (twice the thickness of a single rule). The thickness of each of the rules should be half the thickness of a single rule and that of the gap be the same as the thickness of a single rule. 40.3.21 Reset. The resetting of counters and string variables declared in the Resource Description (via the Counter or String constructs). Characteristics - Definitions: Values - Definitions: Reset Control - The list of NMTOKENS unique Counter Ids or Savetext Names to be reset to the initialized value of the corresponding variable or Float Location Ids whose contents should be flushed. EXPLANATION: a. A counter is reset to its initialized value (as defined in the Counter specification for this Counter ID in the Resource Description) when it appears in the Reset Control list associated with an e-i-c and that e-i-c is encountered in the source document. b. A string variable (Savetext Name) is reset to its initialized value (as defined in the String specification for this Savetext Name in the Resource Description) when it appears in the Reset Control list associated with an e-i-c and that e-i-c is encountered in the source document. c. The contents of all Float Locations whose ID are in the Reset Control list is "flushed." For Float Type of Once and Multi-Reference, flushing means the floats are forced out into the output stream preceding any material the current e-i-c would supply to the output stream even if this would violate the floating constraints. For Float Type of Repeat at Page Break, the float locations are emptied without contributing anything further to the output stream. 40.3.22 Ruling. The drawing of a horizontal rule. Characteristics - Definitions: Values - Definitions: Thickness Size/Distance Length Type - The method for List (Specific, Relative) prescribing the length of the rule. Specific Length - The measure of the rule. Size/Distance Relative Length - The length of the rule List (Column Width, Text Width) relative to a layout area. Vertical Offset - A vertical adjustment Size/Distance >from the baseline. Placement - Placement of the rule before List (Before, After) or after the element content. Rule color - Color of the rule. List (Black, White, Red, Orange, Yellow, Green, Blue, Violet, Brown, Gray) Rule Percent - Percent giving color Integer density of the rule. Type List (Blank, Single, Bold, Double, Triple, Dot, Dash) EXPLANATION: a. Either a Specific Length or a Relative Length can be specified. A Specific Length indicates a known measure. A Relative Length indicates the rule should automatically be drawn to the full width of the Column Area or to the "Text Width" which is the column width after indent values are applied. b. If Textbreak's Start Line is not in effect, a Specific Length must be given, and the rule will be drawn in-line with the surrounding text. It is an error for the Specific Length to be greater than the available space. c. A positive Vertical Offset raises the rule above the baseline. d. The Placement characteristic indicates whether to draw the rule before or after the element content. e. The integer value for Rule Percent is specified as a percentage. For example a value of "80" means 80% of black. f. When Ruling is specified multiple times, or is specified along with Puttext, Putgraph, and Usetext, the order of the generated data in the output stream should appear in the order in which the characteristics are specified for the e-i-c (both before and after the content). 40.3.23 Enumeration. The ordering of like elements. The ordering is a property of individual elements, which may be combined to form a compound number. Note that counters referenced by this category must be declared using the Counter construct that appears in the Resource Description. Characteristics - Definitions: Values - Definitions: Increment - The number by which Size/Distance to increment the counter for the element before using it this time. Counter ID - A unique name IDREF assigned to a counter. Set Value - A toggle indicating Toggle whether the counter is reset to zero before the Increment value is applied. EXPLANATION: a. The counter associated with an e-i-c is incremented by the Increment each time that e-i-c is encountered in the source document. b. If the Set Value toggle is enabled, the counter specified by the Counter ID is reset to zero before any increment is applied. (This has the effect of setting the Counter to the Increment value.) c. Compound numbers are specified through the Source of the Usetext category or the Construction Rule. d. Specifying Enumeration only sets up the characteristics for a counter associated with an element. To actually specify the position of the counter in the output, the counter must be used in the Source of a Usetext specification (either directly by its Counter ID or through its inclusion in a Construction Rule of a Savetext). e. See 40.1.4.24 for a discussion on the order of processing of multiple Savetext's, Usetext's, and Enumerate's. 40.3.24 Puttext. Describes system-generated text that appears in the output data stream. Characteristics - Definitions: Values - Definitions: Puttext Literal - The string String that appears. Placement - Whether to place List (Before, After) the Puttext literal before or after the content of the element. EXPLANATION: a. This characteristic is used to specify a string of text that is generated by the system and is put into the text stream. For example, the system may automatically generate the "This Page Intentionally Left Blank" string for use on blank pages. b. All characters appearing in the Puttext Literal String are reproduced. Should the string require a quote, the alternate quote should be used to enclose the Literal. For example, if a double quote (") is used within the string, the single quote (') should be used to enclose the Literal, and vice versa. c. When Puttext is specified multiple times, or is specified along with Ruling, Putgraph, and Usetext, the order of the generated data in the output stream should appear in the order in which the characteristics are specified for the e-i-c (both before and after the content). d. The Puttext content is placed immediately before or after the contents of the element (properly mixed with other Puttext, Putgraph, or Usetext generated data); any Prespace or Postspace of the element or any effects of other characteristics of the element (such as those due to Textbreak, Keeps, etc.) occur previous to "Before" generated text and subsequent to "After" generated text. 40.3.25 Putgraph. Describes system-generated graphics that appear in the output data stream. Characteristics - Definitions: Values - Definitions: Graphic Name - A reference to Pointer the graphic that is to appear. Width - The width of the graphic. Size/Distance Depth - The depth of the graphic. Size/Distance Placement - Whether to place the List (Before, After) graphic before or after the content of the element. Scale to Fit Toggle Horizontal Scaling Integer Vertical Scaling Integer Horizontal Offset Size/Distance Vertical Offset Size/Distance Rotation Toggle EXPLANATION: a. This characteristic is used to specify graphics that are placed within running text, for example a symbol. For purposes of positioning, the composition system should treat the graphic as a single character. b. When Putgraph is specified multiple times, or is specified along with Ruling, Puttext, and Usetext, the order of the generated data in the output stream should appear in the order in which the characteristics are specified for the e-i-c (both before and after the content). c. The Putgraph content is placed immediately before or after the contents of the element (properly mixed with other Puttext, Putgraph, or Usetext generated data); any Prespace or Postspace of the element or any effects of other characteristics of the element (such as those due to Textbreak, Keeps, etc.) occur previous to "Before" generated text and subsequent to "After" generated text. d. The Width and Depth characteristics specify a bounding box, similar to the reproduction area Graphic characteristics, which represent the amount of space reserved on the presentation media for the graphic. e. If either the Width or Depth characteristic is zero, then it is assumed that a graphic design width and design depth are available from the graphic data. If both width and depth are zero, the graphic design width and design depth are used to determine the bounding box dimensions; if only one is non-zero, then the other one will be determined using the proportion of graphic design width to graphic design depth. f. If both width and depth are set to zero and the incoming graphic does not provide these precise measurements, the depth will default to the current font size and the width will be determined by using the rule in the preceding note. g. The Scale to Fit characteristic allows the graphic to be scaled as needed to fit the size of the bounding box. Horizontal and Vertical Scaling characteristics take precedence when they have values other than "0". If both width and depth characteristics are zero, then the Scale to Fit characteristic has no effect, and the graphic design size will be used subject to any Scaling. h. If either the width or depth characteristic is non-zero, and Scale to Fit is not in effect, the graphic image may be a different size than the bounding box. Whenever this is the case, the graphic image is aligned with the lower left corner of the bounding box, prior to shifting per the Horizontal or Vertical Offset. i. Horizontal Offset and Vertical Offset are not subject to Scaling. These do not move the bounding box; they shift the graphic image within the bounding box. 40.3.26 Savetext. Describes text content to be saved for use elsewhere. Characteristics - Definitions: Values - Definitions: Savetext Name - A unique name NMTOKEN for the saved text. Construction Rule - Rules for String specifying the construction of saved text. The string may contain an indicator for the element content, literals, and unique names of other saved text and counters. Placement - Whether to save List (Before,After) the text before or after the content of the element is processed. Append - Indicates whether the Toggle text to be saved should replace text already saved to this Savetext Name or append itself onto the text currently saved to this Savetext Name. Start Position - The position Integer within the string to begin saving characters. End Position - The position Integer within the string to stop saving characters. Delimit - The character, or String string of characters, used to delimiter strings in the source. Occurrence - The occurrence of Integer a particular delimiter. EXPLANATION: a. This characteristic is used specifically for saving portions of text for use by the Usetext characteristic for other purposes. For example, it might be used to save section titles for use in a Table of Contents. b. The position of the element's content within the saved text is denoted by "#CONTENT" in the Construction Rule. If "#CONTENT" does not appear, no content is saved. When "#CONTENT" does appear, the entire content of the element, including any children it may have, is saved, so that it can have an effect when the saved content is used. c. The Construction Rule string allows for specification of the element content, literal text, references to saved text or counter values, spacing and padding with a unit expression, and pseudo-elements. Entries within the string are separated by a comma and optional spaces. Element content in the Construction Rule is denoted by "#CONTENT". Literal text, including the space character, is placed within backslashes. References to non-keyboard characters are made with an entity reference, as in any string. References to the names of saved text or counters appear with no delimiters. In addition, the style of a counter may be specified to override the style assigned to it by immediately following the counter name with "[style specification]", where style specification is "AR" (Arabic), "RU" (Roman uppercase), "RL" (Roman lowercase), "AU" (Alpha uppercase), or "AL" (Alpha lowercase). Specification of spacing is a number followed by a unit expression (with an optional initial "@" or "*" to indicate a padding specification). References to pseudo-elements are indicated by giving the name of the pseudo-element delimited by (1) an initial "<" to indicate the start of the pseudo-element or (2) an initial "</" to indicate the end of the pseudo-element; and in both cases, the reference is also delimited by a final ">". (Note that pseudo-element references provide a way to reference an e-i-c, but they are not intended to act as embedded SGML tags; they have no content model, can have no attribute specification, and must always have both their start and end explicitly indicated.). Any savetext textid variable whose name is filled in from a source document attribute is time-independent. The following examples illustrate these rules. To express "CHAPTER 1", where the value of the chapter counter (chapct) is "1": <savetext conrule="\CHAPTER \,chapct"> Or alternately: <savetext conrule="\CHAPTER \,chapct[RU]"> Or to express the same title with two em spaces at the end: <savetext conrule="\CHAPTER \,chapct,2em"> To express a paragraph number with the chapter counter (chapct), a hyphen, and the paragraph counter (para0ct): <savetext conrule="chapct,\-\,para0ct"> An initial "@" or "*" preceding a unit expression indicates that the contents of this conrule up to the point of this expression should be padded on the right with space until the width of this contents is the given amount. In the case of a "@", if the content's width already exceeds this amount, no padding is added; in the case of a "*", if the content's width already exceeds this amount, a new line is forced and the new line is padded out to the given amount. Therefore, to express a sequential list item number (seqlstct) padded to a width of 1.5 picas: <savetext conrule="seqlstct,\.\,@1.5pi"> (Then, if the item has a First Line indent exactly 1.5 picas less than its Left Indent, the initial letter of all lines will align vertically provided the item number does not exceed a width of 1.5 picas.) To save the content of the section title (which is the current e-i-c) for eventual processing as part of the table of contents: <savetext textid="toc" append="1" conrule="<toc2>,#CONTENT,<tocpg>,folioct,</tocpg>,</toc2>"> This assumes an e-i-c entry in the FOSI for the "toc2" pseudo-element whose associated formatting characteristics are set to be appropriate for a section title entry in the table of contents, an e-i-c entry in the FOSI for the "tocpg" pseudo-element whose characteristics help set a page number in the table of contents, and a FOSI-defined counter called "folioct" whose value is the current page number. This entry, as well as all others saved with textid="toc" provided they all have append="1", would be available for retrieval by a Usetext. Considering the above example, if it were desired at some point to forget all that has been saved to textid="toc", the following Savetext construct could be used: <savetext textid="toc" append="0" conrule=""> Note that FOSI variables such as counters and previously saved text are expanded (that is, their values are determined) at the time they first appear in the Construction Rule. However, pseudo-element context (as well as the context of any elements that may have been saved within the #CONTENT)--which will be used to determine which e-i-c to match in the FOSI as well as parentage for inheritance--should be based on the context in which the saved text is used via the Usetext. A FOSI counter is time-dependent; that is, its value at any particular point in the document is the value last saved into it; if no save has yet been done to the counter, its value is the value set for the counter in the resource description. A FOSI Savetext variable may be time-dependent or time-independent; time-independence allows for forward references to work (although how this is accomplished is left to the FOSI/output system implementation). If a FOSI Savetext variable is time-independent, its value is assumed to be available throughout its scope; if it is time-dependent, its value at any particular point in the document is the value last saved into it (if no save has yet been done to the variable, its value is the value set for the variable in the resource description if any, or else the null string). A FOSI Savetext variable is time-independent if the value of its Time Status attribute in the resource description is enabled; otherwise, the variable is time-dependent. In the first case, the time-independent value of the variable is its value at the end of the element instance specified by the variables Scope attribute in the resource description (or else at the end of the document element). d. See 30.3.6 for a discussion on the order of processing of multiple Savetexts, Usetexts, and Enumerates. e. Ordinarily when a subsequent Savetext is done with the same Savetext Name as a previous Savetext, the subsequent one replaces the previous one. This is the behavior when the Append characteristic has the value "off" (its default). However, if the value of the Append characteristic is "on", the Savetext's Conrule value would be "appended" to the text already saved to this Savetext Name. Using the Append characteristic, one can accumulate text from the document to aid in the production of tables of contents and similar constructs. f. When both start position and end position are specified, the delimiter is ignored. In this case, all of the characters in the string specified in the source (Construction Rule) between start position and end position inclusively are saved in their original order into Savetext Name. When counting into the string, only text characters of the Construction Rule are counted including literals and text characters from #CONTENT. Dimensions, pseudo-elements, counters, and children (both tags and content) and external entity references picked up in #CONTENT are ignored. Character entity references are each counted as a single character position, and cannot be matched by a Delimiter character. g. The first position in the string is considered to be position one. h. When one of Start Position and End Position is not specified, the entire value of the Construction Rule is saved into the Savetext Name. i. When a Delimiter is specified and neither Start Position nor End Position is specified, the string up to but not including the first occurrence of the Delimiter is saved into the Savetext Name. j. When Occurrence is specified and Delimiter is being used, the string between the referenced Delimiter and the previous Delimiter is saved. The end of the string is considered to be the last delimiter. If there are fewer than the specified number of delimiter occurrences, the null string is saved in the Savetext Name. When Occurrence has the value 1, the string up to but not including the first occurrence of the Delimiter is saved into the Savetext Name. When appended to such a variable reference in a construction rule in the pageres, header, or footer, the FI modifier implies that the value of the variable should be the first value assigned to that textid on the page (or, if there are no assignments to this textid on the page, the value of this variable at the start of the page); the TO modifier implies that the value to be used is this variable's value at the top (the very start) of the page; and BO implies that the value to be used is this variable's value at the bottom of the page. The qualifier FB implies that the value to be used is an ordered collection of all of the values of that variable on the page, including the values corresponding to the FI and BO qualifiers, and all values in between; the TB modifier implies that the value to be used is an ordered collection of all of the values of that variable on the page, including the values corresponding to the TO and BO qualifiers, and all values in between. Ordinarily, when a savetext/usetext is associated with an e-i-c instance in the flowing text, the value of all time-dependent variables referenced in that conrule/source is the value at the time the e-i-c instances's start tag (if placement is before) or end tag (if placement is after) is encountered. However, if a savetext textid variable's value is set (via savetext) in the page resource (pageres) element of a page description, its "current value" at the time the e-i-c instance's start/end tag is encountered depends on whether one considers the pageset processing to occur before or after the flowing text is collected for the current page. When a variable whose value is set in the page resource element appears in a construction rule outside of the page description, one of the two modifiers [TO] or [BO] can be appended to it. The TO modifier implies that the value of the variable that should be used in this savetext/usetext is the value just prior to the associated pageset processing, whereas the BO modifier implies that the value that should be used is that immediately following the associated pageset processing. In the third case above, the results of any changes to a variable specified by savetexts or enumerates in the flowing text, whose value is also changed in any page resource, header, or footer, are undefined unless all e-i-c which specify such changes in the flowing text also have the Start Page characteristic set. In this case, changes to the variable specified in the flowing text take effect before the pageset processing for the page on which the last character will be placed. Example : Assume that the following usetext appears in the header of a page of a dictionary, where the e-i-c for each word in the dictionary contains a savetext to the textid "currword" : <usetext source="currword[FB]"> Also assume that the e-i-c for the <word> element in the dictionary contains a savetext similar to : <savetext textid="currword" conrule="<hword>,#CONTENT,</hword>"> This combination of savetexts and a usetext will produce a list in the header of all of the words where some part of their definition appears on the page. The e-i-c for hword could specify any special formatting or leading, or whatever the document design requires. 40.3.27 Usetext. Describes what to do with text saved from some part of the document. Characteristics - Definitions: Values - Definitions: Source - Reference to saved data. String Placement - Whether to place the text before List (Before, After) or after the content of the element. Usage Rule - Describes what to do with the Integer saved text. Usage Parameter - Modifies String the operation of the specified Usage Rule EXPLANATION: a. This category is used to output saved data. Specifically, it uses data saved with the Savetext, Enumerate, and Character Fill characteristics. Saved data is identified in the Source by unique names assigned to the saved data. A Usage Rule may be applied to the data before placing the result in the output text stream. b. The syntax for the Source is the same as that for the Savetext Construction Rule and is described in detail in 40.3.26. This allows for specification of multiple pieces of saved data in conjunction with literal text. c. When Usetext is specified multiple times, or is specified along with Ruling, Puttext, and Putgraph, the generated data in the output stream should appear in the order in which the characteristics are specified for the e-i-c (both before and after the content). d. The Usetext content is placed immediately before or after the contents of the element (properly mixed with other Puttext, Putgraph, or Usetext generated data); any Prespace or Postspace of the element or any effects of other characteristics of the element (such as those due to Textbreak, Keeps, etc.) occur previous to "Before" generated text and subsequent to "After" generated text. e. See 30.6 for a discussion on the order of processing of multiple Savetext's, Usetext's, and Enumerate's. f. If any userules are used which are not supported by this specification, they will be specified by a negative integer. g. The Usage Parameter characteristic is used to provide parameters to the specified userule. This characteristic is ignored unless a non-zero userule is specified. The form of this characteristic is the same as that of the Puttext Literal characteristic. The syntax and semantics of the string specified for this parameter are determined by the specific userule with which it is used. 40.3.27.1 Sort Userule. Userule #1. To perform sorting. Sorting is performed on data that appears in the source of a usetext. Data shall be specified as records. Within each record will be one and only one key. Both the records and keys shall be scoped by pseudo-elements. Sorting will be performed on the textual data within each key. Parameters: Parameters shall be separated by commas. Values for parameters one through four shall be provided. Values for parameters five and six are optional. Parameter 1: Type of sort to be performed. One value from the following list shall be used: alphabetic, numeric, refdes, tonumber, or partnum. Parameter 2: Either an "a" or a "d" to indicate ascending or descending. Parameter 3: Name of the pseudo-element that serves as the record indicator. Parameter 4: Name of the pseudo-element that serves as the key field for sorting. Parameter 5: Names of elements, separated by whitespace, whose content shall be ignored when sorting. Parameter 6: Valid for alphabetic sorts only. Alphabetic sorts shall be case-insensitive unless this parameter is specified. If a "cs" appears in this position and an alphabetic sort is specified in parameter 1, the sort will be performed case-sensitive. For case sensitive sorts, the letters "A"-"Z" are considered as occurring before the letters "a"-"z". Result: The text that will appear in the output stream after the userule has been processed will be determined as follows: a. Records will be reordered in the proper sequence depending on the setting of the first parameter. All sequences of whitespace shall be treated as a single space. Leading and trailing whitespace shall be ignored. In addition, keys that evaluate equally when sorted with an ascending sort shall retain their relative order in the sorted list. Keys that evaluate equally when sorted with a descending sort shall appear in the sorted list in opposite order as they appeared in the original list. b. The sorting orders are as follows: 1. alphabetic - the content of this pseudo-element is sorted in alphabetical order on a character by character basis. The collating sequence shall be ASCII. 2. numeric - the content of this pseudo-element is sorted in numeric order. Numeric is defined as applying to non-negative integers only. In addition, leading 0s shall have no affect on sorting order, (i.e. "02" is equivalent to "2".) 3. refdes (Reference Designation) a reference designation takes the following form: optional sequence of numbers, followed by an optional group consisting of a sequence of letters followed by a sequence of numbers, which may occur one or more times. Each sequence of letters shall be sorted in alphabetical order, while each sequence of numbers shall be sorted in numeric order. Lower case letters are disallowed. The leftmost sequence is the most significant. All entries without the initial numeric sequence shall appear before all entries with the initial numeric sequence. An example of a sorted reference designation sequence is: A1B2 A1B3 A1B10 A1B11 A2C2 A2C2D3 AB1C2D3 11A1D2 12A1D2 12A1D3 100P 111A 4. tonumber (TO Number) - the content of this pseudo-element is sorted as follows: Each TO Number is broken into fields separated by hyphens. The leftmost field is the most significant, while the rightmost field is least significant. A refdes sort shall be applied to each field. In addition, parentheses (the characters "(" and ")") shall be ignored by the sort process. Special characters shall be considered as occurring after "A"-"Z". In addition, all like special characters shall be grouped together, although the order is implementation dependent. For example, "AB" shall occur before "A/", "B/", and "A#". In addition, the last three sequences can appear as "A/", "B/", "A#" or "A#", "A/", "B/". An example list of sorted TO Numbers follows: 00-25-234 1-1A-14 1-1(B)-14 1-1C-14 1-1/-14 1F-16A-2-36JG-00-1 1F-16A-2-36JG-22-1 2B-22-33A 11B10-ARN15-2 11B11-TWP-2-1 100B2-C11 100#2-C11 5. partnum (Part Number) - part number arrangement shall begin at the extreme left and continue from left to right, one position at a time. For the first character of the part number, the letters A through N and P through Z take precedence over the numerals 0 through 9. (Alphabetic Os are considered numeric zeros. It is valid to make this substitution before sorting, and to retain the substituted value in the subsequent presentations.) For the second and succeeding characters of a part number, precedence is as follows: (1) diagonal (the "/" character), (2) period, (3) dash, (4) letters A through N and P through Z, (5) numerals 0 through 9. Lower case letters are disallowed. The following is a sample arrangement: AN931-4-13 A2460 A317 A32 B/1 B.1 B-1 B12 B2 S/1 1140 121873 128 16.W2 16W060 32P010-1 32P0101 39A46 Sample usage: Consider the following FOSI fragment. <savetext textid="sortdata" conrule="<record>, <item>,\SGML\,</item>, <def>,\Standard Generalized Markup Language\,</def>, </record>, <record>, <item>,\FOSI\,</item>, <def>,\Formatting Output Specification Instance\,</def>, </record>, <record>, <item>,\DTD\,</item>, <def>,\Document Type Definition\,</def>, </record>, <record>, <item>,\DTD\,</item>, <def>,\Sometimes wrongly used as Document Type Declaration\,</def>, </record>"> <usetext source="sortdata" userule="1" useparm="alphabetic,a,<record>,<item>"> After the userule is applied, the equivalent usetext would be: <usetext source="<record>, <item>,\DTD\,</item>, <def>,\Document Type Definition\,</def>, </record>, <record>, <item>,\DTD\,</item>, <def>,\Sometimes wrongly used as Document Type Declaration\,</def>, </record>, <record>, <item>,\FOSI\,</item>, <def>,\Formatting Output Specification Instance\,</def>, </record>, <record>, <item>,\SGML\,</item>, <def>,\Standard Generalized Markup Language\,</def>, </record>"> Note that the relative order of both DTD entries is preserved in the equivalent usetext. If case-sensitivity is desired, the following would be a sample usetext: <usetext source="sortdata" userule="1" useparm="alphabetic,a,<record>,<item>,,cs"> If the key field contained an element named "footnote" whose content should be ignored by the sorting process, the following would be a sample usetext: <usetext source="sortdata" userule="1" useparm="alphabetic,a,<record>,<item>,footnote,cs"> Note that parameter 5 applies to elements that occur in the source document, not pseudo elements, therefore the syntax is slightly different. 40.3.27.2 Userule #2. To determine most general SSSN number. The most general SSSN number is determined from data contained in the source of the usetext. The source of the usetext shall contain a whitespace separated list of SSSN numbers. A SSSN number is defined as being in the form DD-DD-DD where D is a digit from 0-9. Parameters: None. Result: The text that will appear in the output stream after the userule has been processed will be determined as follows: 1. Consider the first character as being the current character 2. Consider the current character of each of the SSSN numbers that appear in the savetext a. If all of the characters are identical, place the character in the output stream. If not, go to step 3. b. If all the characters in each SSSN number have been considered, end this algorithm. c. If all the characters in each SSSN number have not been considered, consider the next character as being the current character. Go to step 2. 3. If each of the characters are not identical, place a "0" in the output stream. In addition, fill all remaining numeric positions with a "0", and fill all hyphenated positions with hyphens. End this algorithm. Sample usage: Consider a savetext string with savetext name of "SSSNlist". SSSNlist contains the following:"20-21-30 20-22-30 20-22-32 20-22-43". After applying the above userule (<usetext source="SSSNlist" userule="2">), "20-20-00" would be placed into the output stream. Implementation of the above userules is left to the methods best suited for each processing system. 40.4 Composition - graphics. This section covers the treatment of graphics. The characteristics described in this section allow a formatting system to insert graphic entities into a document according to the constraints specified by the original illustrator and the author. 40.4.1 Concepts. 40.4.1.1 Definition of terms. The Output Specification provides special characteristics for the handling of source elements used to designate illustrations or drawings, known as graphic elements. Graphic elements are composed within a special composition area on the page known as a reproduction window. Special sizing and placement characteristics are available for graphic elements. A graphic is a single illustration with no other text associated with it. A macrographic is a collection of graphics that are overlaid in a single reproduction area. 40.4.1.2 Sources of graphics information. A graphic element is either a non-SGML external entity (usually a graphics-encoded file) or an SGML marked-up element. Non-SGML graphic entities are usually associated with an empty element in the source DTD. In the case of non-SGML entities, it is assumed the graphic object has an inherent "bounding box" that can be used to size and place the graphic within the reproduction window. In the case of SGML marked-up elements, such a bounding box must be defined for each block of text (element). Sizing capabilities, such as scaling, are not available for text elements. The definition of the bounding box includes its width and depth and a specification of which corner is to be used as the reference point for placement purposes. The bounding box itself is placed relative to the reproduction area. Within the bounding box, composition characteristics are used to compose the text and are relative to the bounding box. In other words, the bounding box can be thought of as the current flowing text area. Graphic elements often have associated information about how to display the graphic. This information can reside in several places: a. Specified in a FOSI b. Specified in source document attributes c. Data attributes specified for the data content notation d. System-specific graphics parameters. The Output Specification addresses only a and b. For any graphics characteristic, if no value is specified in the FOSI or source, it is left to the system to determine the value from other sources. 40.4.1.3 Interaction of the reproduction window, sizing, and placement. Specifying information for graphic element display can be thought of as a three-step process: a. Defining a reproduction window into which the graphic element is to be placed. b. Determining which portion of the graphic is to be displayed or determining a bounding box for text. c. Specifying how the graphic is to be scaled and how the graphic or text block is to be positioned in the repro window. A reproduction window can be associated with a single graphic element or with a non-graphic element that is simply a container for one or more graphic elements. In the case of a container, no sizing or placement information is specified. In the case of graphics or text blocks within the container, no repro window is specified, but sizing (for graphics) and placement information is. The graphic or text block is placed into the repro window associated with its nearest ancestor in the source document. 40.4.1.4 World coordinates. The world coordinate system is used to describe the two-dimensional space in which the graphic is defined and placed. The point of origin is the lower left corner of the graphic and has the coordinates (0,0). The upper right corner has the coordinates (10000,10000). 40.4.1.5 Assumptions. The Output Specification assumes that there is no conflict between the information provided within the graphic entity and the SGML source provided by the author. 40.4.1.6 Available space. The available space for placement of graphics is constrained by the FOSI Page Models. That is, graphics must be able to fit, after allowed cropping and scaling, into one of the Layout Areas specified by the FOSI. 40.4.2 Graphic characteristics. 40.4.2.1 Reproduction area dimensions. Information about the size of the reproduction area (the area on the presentation media) in which the graphic is to be placed. Characteristics - Definitions: Values - Definitions: Repro Area Width Size/Distance Repro Area Depth Size/Distance 40.4.2.2 Graphic sizing. Information concerning constraints on how to modify the size or view of graphics to be placed in the reproduction area. Characteristics - Definitions: Values - Definitions: Graphic Name Pointer Horizontal Scaling Integer Vertical Scaling Integer Scale to Fit Toggle Lower Left Coordinates String Upper Right Coordinates String EXPLANATION: a. The Graphic Name may be the name of an entity declared in the FOSI or it may be omitted in which case it will be filled in from the source document using a fillval construct. b. Scaling values are interpreted as percentages. c. Scaling is disallowed by supplying a value of "0" for the Horizontal and Vertical Scaling characteristics as well as the Scale to Fit characteristic. d. The Scale to Fit characteristic allows the graphic to be scaled as needed to fit the size of the reproduction area. Scaling is by the same factor in both directions. Horizontal and Vertical Scaling characteristics take precedence when they have values other than "0". e. The sizing coordinates define a section (window) of the graphic. This allows both general cropping functionality as well as the ability to designate a particular portion of the graphic to be used for an illustration. f. The syntax to be used for the Lower Left Coordinate String is "integer,integer" where the first integer refers to the starting position of the graphic window along the horizontal axis and the second integer refers to the starting position of the graphic window along the vertical axis. Thus a Start Coordinate value of "0,0" indicates that the desired graphic window begins at the lower left point of the graphic board. g. The syntax to be used for the Upper Right Coordinate String is "integer,integer" where the first integer refers to the ending position of the graphic window along the horizontal axis and the second integer refers to the ending position of the graphic window along the vertical axis. Thus an End Coordinate value of "10000,10000" indicates that the desired graphic window ends at the upper right point of the graphic board. A specification of "0,0" for the Lower Left and "10000,10000" for the Upper Right designates that the portion of the graphic to be used includes the entire graphic board, whereas "5000,5000" for the lower left and "10000,10000" for the upper right would signify that the upper right quadrant of the graphic would be used for the illustration. 40.4.2.3 Text Block. Information concerning the size and reference point of a text block. Characteristics -Definitions: Values - Definitions: Text Block Width Size/Distance Text Block Depth Size/Distance Horizontal reference point List (Left, Right) Vertical reference point List (Top, Bottom) EXPLANATION: a. When Text Block Depth is not specified or set to zero, the text block has variable depth according to its content, much like a table cell. b. The reference points specify the "fixed" corner of the text block. It is the corner placed at Coordinate Start and End in the Placement category. In the case of variable depth text blocks, the text block depth grows away from the fixed corner, that is, downward if the reference point is "top" and upward if the reference point is "bottom". 40.4.2.4 Placement. Information concerning constraints on where and how to place graphics or text blocks with respect to the reproduction area. Characteristics - Definitions: Values - Definitions: Horizontal Placement List (Left, Center, Right, None) Vertical Placement List (Top, Middle, Bottom, None) Start Coordinates String End Coordinates String Rotation Toggle EXPLANATION: a. Horizontal and Vertical Placement are used to place graphics within a repro area. Either relative (horizontal and vertical) or specific (coordinates) positioning should be specified. That is, use of the Placement and Coordinate characteristics is mutually exclusive. When Start and End Coordinates are supplied, the values for Horizontal and Vertical Placement are ignored. b. The Start and End Coordinate characteristics may be used for placing multiple graphics or portions of graphics in a single reproduction area. When these characteristics are used and Scale to Fit is turned on, the graphic is scaled to fit within the bounds of the coordinates specified instead of the entire reproduction area. If Scale to Fit is turned off and the graphic will not fit in the window specified by the Start and End Coordinates, then the Start Coordinate is to be used as an origin and as much of the graphics as will fit in the window is displayed. End Coordinate is ignored for text blocks, as they cannot be scaled. c. The syntax to be used for the Start Coordinate String is "integer,integer" where the first integer refers to the starting position of the graphic along the horizontal axis and the second integer refers to the starting position of the graphic along the vertical axis. Thus a Start Coordinate value of "0,0" indicates that the lower left point of the graphic is to be placed starting at the lower left corner (point of origin) of the repro area. d. The syntax to be used for the End Coordinate String is "integer,integer" where the first integer refers to the ending position of the graphic along the horizontal axis and the second integer refers to the ending position of the graphic along the vertical axis. Thus an End Coordinate value of "10000,10000" indicates that the graphic is to be placed such that the upper right point of the graphic coincides with the upper right corner of the repro area. e. When the value for rotation is "off" the graphic is placed in the same orientation in which it has been received in. When the value is "on" the graphic is rotated 90 degrees counterclockwise before being placed in the repro area. 40.5 Composition - Tables. This section describes the characteristics necessary for the composition of tables. Tables are treated separately in this specification because they have unique formatting characteristics. Tables are important in technical manuals because they contain and present a large amount of data in a format that shows relationships among the data. The characteristics for tables described below allow for robust and discretionary access and manipulation of data contained within tables, and facilitate exchange with, and use within, databases. Within a FOSI, the table description is used to describe the organization and formatting of an actual table, that is, data organized into a two-dimensional grid. Any associated information, such as title, is described in the style description. 40.5.1 Tables as graphics. While it is recognized that tables are often created and treated as graphic illustrations, it is essential for automated processing of source data that the markup of tabular data be developed in such a way that allows the elements within a table to be mapped to the FOSI table description and that automated publishing systems be able to manipulate and reproduce tabular data through the use of a FOSI. Treating tables as graphics is not precluded, but should be carefully evaluated against requirements for information use. This section deals only with tabular data appropriately tagged. 40.5.2 The structure of tables. Tables have two structures. The source structure describes the organization of table data within the source document. The output structure describes how that data actually appears in a two-dimensional format in the output. The purpose of the FOSI entry for a table is to describe how those two structures are related. 40.5.2.1 Source structure. The source structure of a table is defined in the source DTD. This structure should reflect the logical organization of the data as it relates to its purpose. Typically, however, this structure also reflects the two-dimensional output structure. The following is the source structure for a table as defined in appendix A: Table Title Table Groups Column Specifications Table Head Column Specifications Rows Entries Entry Tables Table Foot Column Specifications Rows Entries Entry Tables Table Body Rows Entries Entry Tables Note that this source structure is "generic", that is, the elements are general and do not relate to any specific type of information that might go into the table. Other source structures for tables could be defined that more specifically detail the table content. For example, a source structure for a Special Tools List table could look like this: Special Tools List Tools Description Part Number Reference In this case, the logical elements in the source structure are more closely related to the data in the table. 40.5.2.2 Output structure and table objects. The output structure of a table is defined in this appendix. A table is a rectangular two-dimensional grid, with non-uniform measures, fixed horizontally and content-determined vertically. The objects within a table are table subset groups, table subsets, columns, rows, and cells. A table is the entire rectangle that takes up space in the Flowing Text Area. Characteristics of the table control the frame. A table subset group is a set of table subsets containing an optional heading subset, an optional footing subset, and one or more body subsets. A table subset is a set of contiguous rows within a table, such as the header, footer, or body. There is no space between table subset groups or table subsets in a table. There are three types of table subsets - heading, footing, and body subsets. The rows of heading or footing subsets are repeated above and below (respectively) each contiguous (unbroken), block of rows from any of the table body subsets in the same table subset group. Thus, if the table body subsets breaks across pages or columns, the heading and footing subsets for that table subset group are repeated. Table subsets may have different numbers of columns, but must be the same width as the table. A column is a vertical collection of cells. A column has some specified width and is the depth of the table subset. A row is a horizontal collection of cells. The width of a row is the width of the table and the depth of a row is the depth of the deepest cell. A cell is the intersection of a column and row and forms the basic area into which table content is placed. Characteristics of the cell control the column and row separators, margins, and alignment. Table objects have the following hierarchy: Table Table Subset Groups (1 or more) Column specifications (0 or more) Table Subsets (1 or more) Column specifications (0 or more) Rows (1 or more) Cells (1 or more) In other words, tables are made up of table subset groups, (typically a single subset group), which contain table subsets, which are made up of columns and rows, which intersect to form cells. 40.5.3 Mapping source structure to output structure. Through the Table Description of a FOSI, the source structure of a table in the source DTD is mapped into the output structure defined in this appendix. Each source element is mapped into one or more table object(s). For example, the table source structure in appendix A has the following mapping: Table Table Tgroup Table Subset Group Colspec Column Spanspec Column Thead Table Subset Tfoot Table Subset Tbody Table Subset Row Row Entry Cell Entrytbl Table Subset Notice that the table title in the source structure does not have a corresponding object in the output structure. Formatting of the table title is specified in the style description. Other table structures may be mapped to the table output structure differently. For example, the source structure for a Special Tools List made up of Description, Part Number, and Reference might be represented with the following simple DTD fragment: <!ELEMENT tools - - (desc, partnum, ref)+> <!ELEMENT (desc, partnum, ref) - o (#PCDATA)> Here, "tools" is mapped to a table in the FOSI, and "desc", "partnum", and "ref" are mapped to cells. To fully specify the output of the table, however, may require specifying characteristics for columns and rows, which do not have corresponding elements in the source. This table, including an implied heading, may be mapped to the table object output structure as follows : Tools Table Table Subset Group Columns (3) Table Subset (heading) Row Cells (3) Table Subset (body) Desc Row Cell Partnum Cell Ref Cell Note that each element may be mapped to a contiguous range of objects in the table object hierarchy, with specification of appropriate characteristics for each. This mapping is accomplished by specifying the table output objects and their characteristics in the charlist of the e-i-c of each relevant element. Each table output object has a category in the output specification, with associated characteristics. The content of a source element must be contained within the lowest level table object specified in the charlist for that source element. Thus, an error would occur if a source element were mapped into a cell, and one of its sub-elements were mapped into a table subset. The range of table objects into which a source element is mapped must be contiguous in the table object hierarchy. It is an error for an element to be mapped to a discontinuous range of elements. Thus, an error would occur if a FOSI attempted to map an element into a table subset and a cell, but not into a row. To place text or graphics directly from the FOSI into the output table objects, as shown in the above mapping, use the appropriate table object categories in the subchars specification of a usetext, puttext, or putgraph. The e-i-c for source elements to be mapped into table objects may use the att and specval or fillval constructs to create table specifications which are dependent on attributes of the source document elements. This supports the implementation of named table and table group styles. 40.5.4 Text flow rules of tables. Text flows within tables from left to right and from top to bottom. That is, the first column of the first row (the first cell) is filled with the necessary text; then the second column of the first row (the second cell) is filled. After the last column of the first row is filled, text flows to the first column of the second row, and so on. Whenever two or more cells are spanned, they are treated as a single cell with respect to the flow of text and filled with its content in the upper left cell only. Columns are implicitly numbered starting with 1 at the leftmost column and incrementing by 1 to the right. Rows in each table subset are implicitly numbered starting with 1 at the top row and incrementing by 1 to the bottom. A cell is uniquely identified by its position within a row and column. Spanning is the creation of cells that are larger than a single grid location. Span width indicates the number of columns covered horizontally by a cell. Span depth indicates the number of rows covered vertically by a cell. Spanning occurs in the direction of the flow of cell filling, that is, for horizontal spanning, to the right of the cell where spanning is specified, and for vertical spanning, towards the bottom from the cell where spanning is specified. A spanned cell is considered to be part of the first row and first column in which it occurs. The source markup for a table entry can explicitly specify the name of the column in which the cell contents is to occur. When this information is not supplied, a flow rule is used to determine the cell location. Entries are placed in the "current column", which if not previously specified is column 1. After a column is filled, the current column becomes the column with the number "current column number + span width" (where no spanning means span width is 1). When an entry is explicitly mapped, either by FOSI cellatts or an attribute value in the source document, to a cell in which other source elements have already been mapped, a cell conflict occurs. The result in this case is specified by the value of the "celconflict" characteristic for the entry being mapped. The possible results are: an error, the appending of the mapped entry to the contents of the cell, or the starting of a new row. When fewer entries occur than cells in a row, the remaining cells are treated as if they were each filled by an entry with empty content; that is, row and column separators appear for those cells that would have had them had the cell been filled. 40.5.5 Specifying the style of a table. Two aspects to specifying the style of a table are geometric and text composition. The geometric aspect includes the number of columns, rulings, and margins. The text composition aspect includes font, positioning of text within cells, and generally those characteristics that can be applied to text. Both of these kinds of characteristics can be specified in the FOSI. Special table characteristics are provided to control the style of the table itself. Composition characteristics are used to specify the style of the content. In some cases, such as in the DTD in appendix A, style parameters can be controlled through attributes in the source document. In these cases, these values are "passed through" to the FOSI through the Fillval construct. It is a matter of agreement between the source DTD author and FOSI author which values are "fixed" in the FOSI and which values are actually supplied by the author in the source document. This concept is discussed further later in this section. 40.5.7 Table characteristics. When an e-i-c is mapped to the table output object by the occurrence of the tabatts category in its charlist, unique characteristics for that table as a whole are set up, such as the width, frame thickness, and orientation. 40.5.8 Table subset group and table subset characteristics. When an e-i-c is mapped to a table subset group output object, or a table subset output object by the occurrence of the tgroupatts or subsetatts category in its charlist, unique characteristics for that table subset group or subset are set up, including the number of columns in the table, as well as characteristics for columns, rows, and cells. Columns are implicitly numbered beginning with 1 for the leftmost column and incrementing by 1 for each column. Column names can be associated with each implicitly numbered column. Span names can be established to refer to a horizontal span of columns indicated by the name of the column in which to start and the column in which to end. When no Table Subset characteristics (e.g., number of columns) or column characteristics (e.g., column widths) are specified for a Table Subset object, the characteristics specified for the nearest ancestor in the source document that is mapped to a Table Subset Group are used. If no such element exists, it is an error. In addition, Composition Characteristics can be specified for each e-i-c to specify the style and positioning of the content within the elements. These Composition Characteristics override the Table characteristics already set up for the table objects. Indents specified for the content are additive to the margins established for the cell. 40.5.9 Scope of table characteristics. In general, there is a unique set of characteristics for each table object. In addition, there is a set of "Standard Cell Characteristics" that control the characteristics of a cell but can be specified on any table object. These characteristics include column and row separators, margins, and alignment. When specified on a table object, these characteristics apply to all the cells within the scope of that object. For example, when Standard Cell Characteristics are specified on a column, those values apply to all the cells in the column. When specified on more than one table object, the values for objects "lower" in the hierarchy override the others for the scope of that object; that is, the order of precedence is cell, row, column, table subset, table subset group, and table. Note that this "table object specification inheritance" is different from the "source document characteristic inheritance" feature available elsewhere in a FOSI. The table description categories (tabatts, tgroupatts, subsetatts, colatts, rowatts, cellatts, stdcellatts) in the charlist are intended only for the specification of table output object characteristics. The categories may be used in environments and charsubsets in the Style Description section of a FOSI to define environments and charsubsets which may be used in the Table Description section of the FOSI as part of a table description. The use of any of these categories in an e-i-c in the Style Description section of a FOSI, either directly or by reference to an environment or charsubset, is an error. 40.5.10 The content of tables. While it may be sufficient to specify the formatting of simple text (#PCDATA) within a cell by supplying Cell Characteristics and Composition Characteristics for the cell, there may be a need to specify additional Composition Characteristics when the cell contains more complex element content. For example, lists within table entries may differ from lists in flowing text. These e-i-cs (that are children of the source table "entry") must also be included in the Style Description of the FOSI and the appropriate Composition Characteristics specified. The following Composition Characteristics do NOT apply within tables: Highlight Reverse, Background Color and Background Screen (cell Reverse, Color, and Shading take precedence); Keeps (row breaking takes precedence); Vertical Justification; Textbreak Start Column, Start Page, Page Model ID, and New Page Model; Span (cell spanning takes precedence). 40.5.11 Overriding FOSI values through the source markup. For any particular source DTD, the values of many source attributes may map directly to Table characteristic values. Where this occurs, source attribute values can override any value supplied in the corresponding Table characteristic. A FOSI entry may be constructed such that values are supplied for characteristics but any values supplied in the source override the specified value by using the Fillval construct. Authors need not specify all the attributes available to them. The attributes exist to allow authors the necessary freedom to create an exception to a particular Table Style. For example, an author may wish to specify that a particular column should have its contents center-aligned when referencing a Table Style that specifies that all columns are left-aligned. The author then needs only to specify a single attribute to get the desired result, as the "center" value the author specifies for the "align" attribute can override the "left" value specified in the FOSI. The "left" value remains in the FOSI so that the exception specified by the author remains the exception it is supposed to be. 40.5.12 Table Characteristics. The characteristics listed below are unique to tables, and may be used in conjunction with Composition Characteristics to fully specify the output of tables. 40.5.12.1 Table Characteristics. Characteristics that apply specifically to the table element. Characteristics - Definitions: Values - Definitions: Width Type List (Specific, Relative) Specific Width Size/Distance Relative Width Percentage Frame List (All, Top, Bottom, Top & Bottom, Sides, None) Frame Thickness Size/Distance Frame Style List (None, Blank, Single, Bold, Double, Triple, Dotted, Dashed) Continue With Row Toggle Separator EXPLANATION: a. FOSIs have a minimum of one Table Style specified as a result of supplying a default value for each Table characteristic. b. Width Type indicates whether the width of the table is a particular specified value or is relative to the column or page in which it is placed. When "specific" is specified, a value should be supplied for the Specific Width characteristic. When "relative" is specified, a value for the Relative Width characteristic should be supplied to indicate the percentage of the column or page the table is to fill. c. The Frame Thickness is measured from the outside edge of the Table boundary inwards. Notice that this differs from the other rule separators. d. When the Continue With Row Separator characteristic is "on", a Table Row Separator appears under the last Table Row on a Column or Page and above the first Table Row on the succeeding Column or Page. When "off", both Row Separators are omitted. 40.5.12.2 Standard Cell Characteristics. Characteristics that apply to cells, which may be specified on any table object and apply to the cells within the scope of that object. Characteristics - Definitions: Values - Definitions: Column Separator On Toggle Row Separator On Toggle Column Separator Width Size/Distance Row Separator Width Size/Distance Column Separator Style List (CBlank, CSingle, CBold, CDouble, CTriple, CDotted, CDashed) Row Separator Style List (RBlank, RSingle, RBold, RDouble, RTriple RDotted, RDashed) Left Margin Size/Distance Right Margin Size/Distance Top Margin Size/Distance Bottom Margin Size/Distance Horizontal Alignment List (Right - Flush Right/Ragged left, Left - Flush Left/Ragged right Center - Centered Justify - Flush Left & Flush Right, Char - A character to align to the left of) Vertical Alignment List (Top, Middle, Bottom) Alignment Character String Alignment Character Offset Integer (percentage) Reverse Toggle Background Color List (Black | White | Red | Orange | Yellow | Green | Blue | Violet | Brown | Gray) Shading Percentage Rotation Toggle Text Width Size/Distance Break Row Toggle Cell Conflict List (Error | Append | New row) EXPLANATION: a. When Column or Row separators are turned on, they have no effect on the Table Frame. When Column or Row separators are turned on and Frame is turned off, no rule appears around the outside edges of the table. b. Column and Row separators appear centered over the right boundary and bottom boundary respectively. Thus they always appear between columns or rows. The separators shall appear centered between two columns or rows, such that when a column separator is 1 point thick, .5 points impinge on the width of the column to the left of the separator and .5 points impinge on the width of the column to the right of the separator. c. The values for row and column margins for a cell must be greater than half the thickness of any column or row separators that apply to that cell. d. Any highlighting characteristics apply to the full cell area, extending through the margins to the cell separators. e. For shading, 0 is white, 100 is full color saturation. f. When the value for Rotation is "off", the contents of the cell is placed in the same orientation as the Table. When the value is "on", the contents of the cell is rotated 90 degrees counterclockwise. g. The Textwidth characteristic is used only when Rotation is enabled. Textwidth specifies the width to which the text is formatted. When unspecified, Textwidth is the column width minus the left and right cell margins. h. For cells with Rotation specified, the cell contents is formatted to the width specified by Textwidth using any applicable Composition Characteristics; the cell contents is rotated; then cell characteristics are applied. i. No row with cells containing any graphic or rotated text can be split. j. When Tables are allowed to continue across Column or Page boundaries, they shall normally break between rows. When the Break Row characteristic is turned "on" for all cells in a row, then a break across a Column or Page boundary may occur within that row. k. When data from multiple source document elements attempts to occupy the same cell in a table, the action to be taken may be specified by the Cell Conflict characteristic. If specified as "error", an error is noted by the output system; if specified as "append", subsequent source document data are appended to the cell; if specified as "new row", a new table row in the same table subset is started. 40.5.12.3.1 Table subset group characteristics. Characteristics that apply specifically to Table Subsets Groups. Characteristics - Definitions: Values - Definitions: Number of Columns Integer EXPLANATION: a. The value for Number of Columns may be obtained from the source document via the fillval characteristic. 40.5.12.3.2 Table subset characteristics. Characteristics that apply specifically to Table Subsets. Characteristics - Definitions: Values - Definitions: Number of Columns Integer Keep - Keep the whole subset List (Column, Page, None) together within the specified boundary. Subset Type List (Heading, Footing, Body) EXPLANATION: a. The value for Number of Columns may be obtained from the source document via the fillval characteristic. b. The keep characteristic indicates the boundaries across which the subset cannot break, either a column or page boundary. Specifying "column" implies also keeping within the page. c. The subset type characteristic indicates to which of the three table subset types to map this element. 40.5.12.4 Column characteristics. Characteristics that apply specifically to Table Columns. Characteristics - Definitions: Values - Definitions: Column Width String Column Number String Column Name String Span Name String Start Column Name String End Column Name String EXPLANATION: a. Column characteristics are used either to associate a column width and optional column name with an implicitly or explicitly numbered column or to associate the starting and ending column names with a span name. Either Column Width with Column Number and optional Column Name should be specified or Span Name, Start Column Name, and End Column Name should be specified. The width of a span is the sum of the widths of its contained columns. b. The value of Column Number refers to the number of the column in the output structure. It can either be specified in the FOSI or obtained from the source. In a FOSI, a number refers to the implicit column number of a column in the output structure. The keyword "#LAST" is used to refer to the last (rightmost) column regardless of its implicit number. The keyword "#DEFAULT" can be used to specify a set of characteristics to be used when no column characteristics are specified for a column, either explicitly in a FOSI or obtained from the source. The value of Column Number can also be obtained from an attribute value specified for the source element that is being mapped to a column (via a Fillval). When this attribute has no value specified in the source, the Column Number is derived as one greater than the last Column Number specified (derived or explicitly) within the same table group. If no Column Number has yet been specified for the current table group, Column Number is 1. For example, suppose the "colspec" element is mapped to a column and its "colnum" attribute indicates the column number. If the first "colspec" element has no value for "colnum" specified, Column Number is assumed to be 1. If the next "colspec" element's "colnum" attribute has the value "3", Column Number would be "3" and the column characteristics for column 2 would have to be derived from a column characteristic using the #DEFAULT keyword. If the next "colspec" element had no value supplied for its "colnum" attribute, Column Number would be 4, and so on. The column width is specified either as a fixed measure or in terms of units of proportional measure with optional additional fixed measure. Fixed measure is specified as any other width in the FOSI: as a size/distance specification. Proportional measure is specified by an integer followed by "*". The unit of proportional measure is calculated by subtracting the sum of all fixed measures for all columns in a table from the width and dividing the remainder by the sum of the number of proportional units for all columns in the table. For example, the width specification "5*" would indicate five proportional units, while "5*3pt" indicates five proportional units plus 3 points. c. It is an error to fail to provide a Column Width for all columns in the output structure, either through implicit or explicit reference. d. Start Column Name and End Column Name refer to names assigned to columns in the output structure via these column characteristics. The span name is associated with this span of columns. e. It is an error to specify more than one set of column characteristics for a given column, either through implicit or explicit reference. 40.5.12.6 Cell Characteristics. Characteristics that apply specifically to Table Cells. Characteristics - Definitions: Values - Definitions: Column Name String Span Name String Span Depth Integer EXPLANATION: a. Either a Column Name or Span Name should be specified. The Column Name and Span Name refer to the names assigned to a column or span of columns via the Column Characteristics. In the case where both are specified, the Column Name is used. In the case where neither is specified, the text flow rules determine the column in which the cell contents are placed. b. The Integer value for the Span Depth Characteristic designates the number of rows the entry is to straddle. 40.6 Page models and layout characteristics. This section is divided into three major subsections: Concepts, Page Models, and Pagination Characteristics. The Concepts section (40.4.1) describes the general concepts relating to text flow characteristics, bind margins, page model type, and inheritance. The Page Models section (40.6.2) describes the kinds of layout areas that can exist on a page, and what their relationship is to each other. The Pagination Characteristics section (40.4.3) describes the characteristics that can be applied to each of these layout areas. 40.6.1 Concepts. 40.6.1.1 Text flow. As a general rule, text flows into columns on a page, filling each column. If there is more than one column, the text flows from the top of the leftmost column to the bottom of the rightmost column before continuing on the succeeding page. Exceptions to this general rule are discussed in their respective sections, including elements to be placed in the Header or Footer Areas, footnotes, floating elements, and elements affected by the Textbreak and Balance characteristics. 40.6.1.2 Multiple page models. Documents are typically made up of different types of pages. For instance, the body of a manual may have pages containing two columns of flowing text, while the front matter has pages containing a single column. Manuals may also contain foldout pages that have entirely different dimensions from other pages. It is therefore a requirement of a FOSI to describe a Page Model for each type of page to be generated. This specification describes general rules for describing any Page Model required for technical manuals. A logical element can be connected to a specific Page Model. 40.6.1.3 Inheritance. Inheritance is not used for the specification of Pagination characteristics. FOSIs must supply values for all required characteristics of a Layout Area. 40.6.2 Page models. This section describes general rules for creating Page Models. A Page Model defines: a. Each type of Layout Area that is allowed to occur on any page covered by the particular Page Model, and b. How each Layout Area on a page relates to other Layout Areas on the page, in particular, which Layout Areas are contained within others, and what the spatial relationships are among the Layout Areas. 40.6.2.1 Layout areas. Each Layout Area is comprised of Subordinate Layout Areas, unless it is a terminal Layout Area, in which case it is either empty or comprised of composition characteristics. A Page Model shall also define related printing information for paper media such as the bind edge and necessary characteristics for one- or two-sided printing. Each Layout Area is described in the following sections with general rules that apply to all FOSIs. Further, rules that are specified below apply to all allowable Page Models. The following outline gives the structure of the Page Model Layout Areas. Page Set Page Area Top Margin Area Bottom Margin Area Left Margin Area Right Margin Area Header Area Footer Area Flowing Text Area Column Area Footnote Area Gutter Area 40.6.2.2 Page set. A Page Set contains information that applies to a particular Page Area. A Page Area may cover recto pages, verso pages, recto pages with blank backs, verso pages with blank fronts, and blank pages, and the information they have in common makes them part of the same Page Set. There can be any number of Page Sets for a document. Page Sets are referenced by associated unique Ids. Figure 2 gives a graphical representation of the Page Model Layout Area. The model for a page set allows for one or more "recto, verso, blank" triples (plus header/footer redefinitions for blank front/back pages). Whenever processing switches to a different page set, the first page produced using that page set will use the appropriate entry (depending if the page is a recto, verso, or blank page) from the first triple of that page set; the second page will use the appropriate entry from the second triple of that page set; and so on with the last triple in the page set being used for all subsequent pages produced. This allows, for example, for opening pages of a page set to use a different page model than subsequent ones. The most common case will be a page set specification with only one "recto, verso, blank" triple. In the recto and verso elements, there is an optional Page Resource element in which one can include occurrences of the Enumerate and Savetext categories. This allows counters and string variables to be managed on a per page basis. For example, one would most likely increment the counter that is being used to count pages (e.g., as all or part of the page folio) in an Enumerate in the Page Resource element of all pages. 40.6.2.3 Page area. The Page Area is defined as the total physical page area. All other Layout Areas reside within the Page Area. Subordinate Layout Areas: Top Margin Area Bottom Margin Area Left Margin Area Right Margin Area Header Area Footer Area Flowing Text Area 40.6.2.4 Top margin area. The Top Margin is defined as the area between the top edge of the Page Area and the top edge of the Header Area and runs the width of the Page Area. Subordinate Layout Areas. None. EXPLANATION: a. There is no space between the Top Margin Area and the Header Area. 40.6.2.5 Bottom margin area. The Bottom Margin is defined as the area between the bottom edge of the Page Area and the bottom edge of the Footer Area and runs the width of the Page Area. Subordinate Layout Areas. None. EXPLANATION: a. There is no space between the Bottom Margin Area and the Footer Area. 40.6.2.6 Left margin area. The Left Margin is defined as the area between the left edge of the Page Area and left edge of the Flowing Text Area and runs the depth of the Page Area. Subordinate Layout Areas. None. EXPLANATION: a. There is no space between the Left Margin Area and the Flowing Text Area. 40.6.2.7 Right margin area. The Right Margin is defined as the area between the Right edge of the Page Area and Right edge of the Flowing Text area and runs the depth of the Page Area. Subordinate Layout Areas. None. EXPLANATION: a. There is no space between the Right Margin Area and the Flowing Text Area. 40.6.2.8 Change mark area. The Change Mark Area is defined as an area whose boundaries are within the Left or Right Margin or Gutter Areas and runs the depth of the Flowing Text Area plus the Header and Footer Areas. Subordinate Layout Areas. None. EXPLANATION: a. The Change Mark Area does not have an associated element in the OS DTD. The location of the Change Mark Area in the page model is determined by the Change Mark Area Width characteristic, the Change Mark Offset characteristic, and Change Mark placement characteristics. b. The sum of the Width characteristic of the Change Mark Area and the Change Mark Offset characteristic should be less than the Width characteristic of all Margin Areas in which the Change Mark Area may appear. c. Change Mark Areas are only used to place change marks as indicated by the Change Mark Category. 40.6.2.9 Header area. The Header Area is defined as the area immediately below the Top Margin and above the Flowing Text Area. The Header area is bordered by the Left and Right Margin Areas. The Header Area may contain items such as publication number and security classification. Some of these items may be repetitive from page to page and some may change from page to page. Some Header information may be determined by the actual content of the page. The depth of the header can vary depending upon its contents. Subordinate Layout Areas. None. EXPLANATION: a. There is no space between the Header Area and the Top Margin Area. b. When header and footer grow past maximum they obtain extra depth from the flowtext area and spaceabove and spacebelow remain constant. 40.6.2.10 Footer area. The Footer Area is defined as the area immediately above the Bottom margin Area and below the Flowing Text Area, and is bordered by the Left Margin area and the Right Margin Area. The Footer Area may contain items such as the folio (page number) and revision date and number. Some of these items may be repetitive from page to page, and some may change from page to page. Some Footer information may be determined by the actual content of the page. The depth of the footer can vary depending upon its contents. Subordinate Layout Areas. None. EXPLANATION: a. There is no space between the Bottom Margin Area and the Footer Area. 40.6.2.11 Flowing text area. The Flowing Text Area is defined as the area below the Header Area, above the Footer Area, and in between the Left Margin Area and the Right Margin Area. The flowing text area may contain items such as flowing text, figures, and tables. The Flowing Text Area may be subdivided into Column Areas that are separated by Gutter Areas. The depth of the flowing text area is equal to the difference between the depth of the page and the sum of the top margin, bottom margin, header, footer, space above, and space below. The width of the flowing text area is equal to the difference between the width of the page and the sum of the left margin and right margin. Subordinate Layout Areas. Column Area, Gutter Area, Footnote Area. EXPLANATION: a. If there is more than one column, the text will flow from the top of the left most column to the bottom of the right most column before continuing on the succeeding page. b. If there is more than one column, the width of the columns shall be identical. c. If there are more than two columns, the width of the gutters shall be identical. d. There may, optionally, be more than one Flowing Text Area specification for a given page specification, in which case each one should be for a different Number of Columns. The various Flowing Text Area specifications would each be used when their respective Number of Columns specification matches the current number of columns being formatted (as affected by the Span characteristic of the Span category). If the value of the current number of columns is one and there is no Flowing Text Area specification for one column, an implicit one column specification that spans all columns would be assumed. If for a given number of columns there is no matching Flowing Text Area specification, it is an error and its resolution is determined by the output system. 40.6.2.12 Column area. The Column Area is a sub-area of the Flowing Text Area. Subordinate Layout Areas. None. EXPLANATION: a. When a Flowing Text Area has a single Column Area, the Width characteristic value of the Column Area must equal the width of the Flowing Text Area. b. When there is more than one column, the width of each column is the same. c. Column characteristics are required even when there is a single column. 40.6.2.13 Footnote area. The Footnote Area is a sub-area of the Flowing Text Area. The bottom of the Footnote Area is typically immediately above the Footer Area, but its depth can vary from page to page or column to column. The Footnote Area is unique in that although the reading direction of its contents is the same as it is for the Flowing Text Area, the placement of its contents cause the Footnote Area to grow upwards within the Flowing Text Area. If the contents of the Footnote Area does not fit within the Maximum Depth characteristic, the text flows to the next Footnote Area. See also section 40.6.3.8 for more discussion of setting up Footnote Areas. Subordinate Layout Areas. None. EXPLANATION: a. The Width characteristic of the Footnote Area is set to either the Column Width or the Flowing Text Area Width area. This determines whether the Footnote Area spans across columns when there is more than one column. 40.6.2.14 Gutter area. The Gutter Area is the space between Column Areas. Its depth is equal to the depth of the flowing text area. Subordinate Layout Areas. None. EXPLANATION: a. When the Gutter Rule Thickness is non-zero, a vertical rule of this thickness (in the given color) is drawn centered in each gutter. b. The integer value for Rule Percent is specified as a percentage. For example a value of "80" means 80% of black. 40.6.3 Pagination characteristics. This section describes the Pagination characteristics that can be attached to Layout Areas. 40.6.3.1 Page set. These characteristics apply to a Page Set, that is, a collection of a recto page, verso page, and blank page. Characteristics - Definitions: Values - Definitions: Page Model ID ID Recto/Verso Toggle Blank Page Toggle Orientation List (Portrait, Landscape) EXPLANATION: a. The Recto/Verso characteristic works in conjunction with the Bind Margin characteristic defined for the recto page in the Page Set. If the Recto/Verso characteristic is turned on, then the verso pages have In Margin and Out Margin Width characteristic values exactly reversed and all elements that have the Quadding characteristic set to "in" or "out" follow the Bind Edge that is currently in effect. If the Recto/Verso characteristic is turned off, then the In and Out Margin retain the same values regardless of whether the page is recto or verso. b. If the Page Set defines a blank page model, then when a blank page is generated (as a possible result of a Start Page characteristic value of verso or recto), the blank page model for the Page Set is used unless the Blank Page characteristic is turned off. Note that a new Page Set takes effect with the first non-blank page generated after the Page Model has changed. Therefore the Page Set that is in effect for the blank page is the one in effect before any page model change that may take place due to the Textbreak characteristics associated with the current element. c. The standard page orientation is Portrait. A landscape page is one in which the contents of the Flowing Text area is rotated 90 degrees counter-clockwise; the rest of the layout areas (e.g., the header and footer areas and right and left margins) remain in place. 40.6.3.2 Page. These characteristics apply to a given page, that is, a given recto, verso, or blank page. Characteristics - Definitions: Values - Definitions: Width Size/Distance Depth Size/Distance In (Bind) Margin List (Left, Top, Bottom) Change Mark Width Size/Distance Change Mark Offset Size/Distance Change Mark Placement List (Left, Right, In, Out, Left/Right) Top Float IDREFS Bottom Float IDREFS EXPLANATION: a. The Width and Depth characteristics specify the width and depth of the Page Area. b. The Bind Margin characteristic can be defined only for the recto page in the Page Set. c. The Change Mark Width specifies the width of the Change Mark Area. All Change Mark Areas have the same width. d. Change Mark Areas shall be placed according to the following rules: 1. When Change Mark Placement is Left, the Change Mark Area appears to the left of all Column Areas by the amount of the Change Mark Offset. The setting of the Recto/Verso toggle has no effect on change mark area placement in this case. 2. When Change Mark Placement is Right, the Change Mark Area appears to the right of all Column Areas by the amount of the Change Mark Offset. The setting of the Recto/Verso toggle has no effect on change mark area placement in this case. 3. When Change Mark Placement is In, the Change Mark Area appears to the "In" side--as defined by the "In (Bind) Margin" characteristic--of all Column Areas by the amount of the Change Mark Offset. The setting of the Recto/Verso toggle may effect the meaning of "In", but its setting has no other effect on change mark area placement. 4. When Change Mark Placement is Out, the Change Mark Area appears to the "Out" side--the opposite of the "In" side--of all Column Areas by the amount of the Change Mark Offset. The setting of the Recto/Verso toggle may effect the meaning of "In" (and hence, of "Out"), but its setting has no other effect on change mark area placement. 5. When Change Mark Placement is Left/Right and the Number of Columns is 2, the Change Mark Area appears to the left of the first Column Area and to the right of the second Column Area by the amount of the Change Mark Offset. For any other value of Number of Columns, a Change Mark Placement of Left/Right is equivalent to a Change Mark Placement of Out. The setting of the Recto/Verso toggle may effect the meaning of "In" (and hence, of "Out"), but its setting has no other effect on change mark area placement. When a border is on the page, the change mark area on the outside of the outermost column must be moved to that column's inside. e. The Change Mark Offset characteristic always has a positive value, and is measured from the edge of the column area to the edge of the Change Mark Area in the direction specified in the previous rule. f. The only place on the page where change marks are required to appear are in the Change Mark Areas. g. The change mark placement characteristic on the flowing text area takes precedence over that on the page area. 40.6.3.3 Margins. These characteristics apply to Margins. Characteristics - Definitions: Values - Definitions: Width Size/Distance Depth Size/Distance EXPLANATION: a. The Width characteristic of the Left Margin and Right Margin specify the width of the margin. b. The Depth characteristic of the Top Margin and Bottom Margin specify the depth of the margin. 40.6.3.4 Header and footer. These characteristics apply to Header and Footer Areas. Characteristics - Definitions: Values - Definitions: Nominal Depth - The preferred Size/Distance depth (what should occur). Maximum Depth - The greatest Size/Distance depth that can occur. Spa Flow Size/Distance EXPLANATION: a. The Nominal Depth specifies the depth that the composition system should strive for in all cases. b. The Maximum Depth should never be exceeded. c. The effect of specifying different values for Nominal and Maximum Depth values allows for variable spacing to be used. d. If only Nominal Depth is specified or if it equals the Minimum and Maximum values, then it is assumed the depth is fixed, i.e., it is not permissible to allow Header and Footer Areas to be variable. 40.6.3.4.1 Vertical quadding and text flow in headers and footers. The vertical quadding category is contained in the content model for the header and footer elements. It may occur 0 or more times in the content of a header or footer characteristic, and separates the contents of the header of footer into groups. Within each group, text is output according to the characteristics specified for each category in the group (sectext, ruling, puttext, putgraph, usetext). Each group is positioned independently within the header and footer area according to the vquad specification for that group. The tops of all groups with a Vertical Quadding characteristic of Top are aligned to the top of the header or footer; the middles of all groups with a Vertical Quadding characteristic of Middle are aligned to the middle of the header or footer; and the bottoms of all groups with a Vertical Quadding characteristic of Bottom are aligned to the bottom of the header or footer. Characteristics-Definitions: Values- Definitions: Vertical Quadding List (Top, Middle, Bottom) EXPLANATION: a. Vertical quadding is used to specify the positioning of groups of elements placed in the header and footer area of the page. b. If the first category in the header or footer is not Vertical Quadding, then the group in the header or footer from the start to the end or the first vquad is treated as though Vertical Quadding of Top had been specified for that group. c. Nominal prespace and postspace are included in the calculation of the top, middle, and bottom of each vquad group in the header or footer. d. The Vertical Quadding category implies a textbrk characteristic of endln="1" for the last category specified in the preceding vertical quadding group, and a textbrk characteristic of startln="1" for the first category in the following vertical quadding group. e. It is possible to write FOSIs where the combination of specifications in a header or footer using the Vertical Quadding category will cause text to overlap. No error is detected by the output system in this case. 40.6.3.5 Security text. Characteristics - Definitions: Values - Definitions: Scope List (Page, Sheet, Document) EXPLANATION: a. The scope characteristic defines the boundaries for consideration when determining the highest security level used. The security text string for the highest level contained within the scope is placed in the header or footer, as defined by the pageset in effect. 40.6.3.6 Flowing text area characteristics. These characteristics apply only to Flowing Text Areas. Characteristics - Definitions: Values - Definitions: Number of Columns List (1, 2, 3, 4, 5, 6, 7, 8) Balance Toggle Space Above Size/Distance Space Below Size/Distance EXPLANATION: a. The value of the Balance characteristic is ignored when the Number of Columns characteristics has a value of "1". b. When the Balance characteristic is turned on, it takes effect in two situations: 1. When an element with Start Page turned on is encountered (when a new page is forced). 2. When an element with the Keep characteristic turned on will not fit on the current page, and a new page is therefore forced. In these cases, the text remaining on the page is balanced within the Flowing Text Area. c. There are no cases where some, but not all, Column Areas occurring within the same Flowing Text Area are balanced. d. The Space Above determines the vertical space between the Header Area and the Flowing Text Area. The Space Below determines the vertical space between the bottom of the Flowing Text Area and the top of the Footer Area. 40.6.3.6.1 Floating area characteristics. These characteristics apply to Flowing Text Areas and Columns. Characteristics - Definitions Values - Definitions Top Floats - an ordered list of IDREFS Float location ID references Bottom Floats - an ordered list of IDREFS Float location ID references EXPLANATION: a. The list of Float location Ids specifies which float layout areas can occur at the top/bottom of the current page/column. The order of the Ids indicates positioning from the top of the page toward the bottom. b. Footnotes will either come out before all Float location areas or after all of them depending on the Footnote Float characteristic of the footnote element in the Page Description. c. It is permitted to include the same Float location ID reference in both the Top and Bottom Floats in the case of one per page floats. This indicates that the output system can place such floats into either location. Such a construct is most appropriately used with a Page Type of After Reference. d. It is permitted to include the same Float location ID reference in both the Column specification (in the Top or Bottom Float) and the Flowtext specification (in the Top or Bottom Float) in the case of once per page floats; this implies that the output system will emit floats (maintaining the first-in-first-out order) as best it can depending on the width of the floats. It should be noted that such a specification can lead to a set of constraints that cannot all be satisfied. e. It is not permitted to include the same Float location ID reference for a Float location whose Type is Repeat at Page Break or Multi-reference more than once per page. 40.6.3.7 Column characteristics. Characteristics - Definitions: Values - Definitions: Width Size/Distance Tolerance Size/Distance Vertical Justification Priority List (Column, Composition) EXPLANATION: a. The Width characteristic specifies the width of all columns. When the number of columns in the Flowing Text Area is 1, the Width is ignored and the flowing text area width area is used. b. The Tolerance characteristic specifies the maximum amount of space that can occur between the bottom of a column and the bottom of the Flowing Text Area when columns are balanced. c. The page immediately preceding a page caused by the Start New Page characteristic is not subject to the Tolerance requirement. d. The Vertical Justification Priority characteristic specifies which set of characteristic values has precedence for purposes of vertical justification: the depth of the Column Area or the Vertical Justification Composition characteristics (Prespace, Postspace, and Keeps) specified for the elements that occur on the page. 40.6.3.8 Footnote placement. Characteristics - Definitions: Values - Definitions: Width List (Column, Flowing Text) Maximum Depth Size/Distance Footnote Separator Thickness Size/Distance Footnote Separator Length Size/Distance Footnote Breaking Toggle Footnote Continue Separator Thickness Size/Distance Footnote Continue Separator Length Size/Distance Footnote Continue String String Space Above Size/Distance Footnote Float Toggle EXPLANATION: a. The Width characteristic specifies whether the Footnote Area is the width of a Column or the Flowing Text Area. b. The Maxdepth characteristic specifies the maximum depth the Footnote Area can have. If nothing is placed in the Footnote Area, it has a depth of 0. c. Footnote separator ruling is disabled by supplying a value of zero to the Footnote Separator Thickness or Footnote Continue Separator Thickness characteristics. d. When the Footnote Breaking characteristic is turned on, footnotes may be continued across columns or pages. e. When a footnote will not fit in the same Column or Flowing Text Area as its reference, and the Footnote Breaking characteristic is turned on, it shall appear in the next Column or Flowing Text Area. If the Footnote Breaking characteristic is turned off, the footnote must be made to fit on the same Column or Flowing Text Area. f. Footnote Separators shall be placed such that the top of the Separator abuts the top of the Footnote Area and extends down into the Footnote Area the amount of its Thickness. g. The Footnote Continue String value is specified using the same syntax described for the Savetext Construction Rule (see section 40.3.26). h. The Space Above determines the vertical space in between the Footnote Area and the Flowing Text Area. i. When the Footnote Float characteristic is turned on, the Footnote area appears closest to the text (in the Column or Flowing Text) preceding any Float location areas. If the Footnote Float characteristic is not enabled, the Footnote area follows all Float location areas. 40.6.3.9 Border specification. The Border Specification associates a name for a border used within a FOSI with an external entity that contains the actual border graphic. Characteristics - Definitions: Values - Definitions: Border Indicator - name of the border String Border Entity - the identifier of Pointer the border entity EXPLANATION: a. The border specification does not indicate that any border is to appear on the pages with which it is associated; it simply identifies the Border Names and associated Border Entities that can occur on the page. b. The border names defined in the Page Description are used in the Border Name characteristic of the Border category to specify the appearance of a border on a page. c. The Border Entity specifies an entity whose public or system identifier identifies a file containing an appropriate graphic to create the border on the page. The referenced graphic should be the complete border graphic appropriately sized for the page and covering the appropriate page sides. The referenced graphic underlays any other images on the page. 50. OUTPUT SPECIFICATION DTD <!-- The following set of declarations may be referred to using a public entity as follows: <!DOCTYPE outspec PUBLIC "-//USA-DOD//DTD OUTPUT SPEC MIL-M-28001 REVB//EN"> --> <!-- NOTE: In order to parse the following Document Type Declaration Subset alone, append the Document Type Declaration statement below to the beginning of the file: <!DOCTYPE outspec [ and the associated "]>" to the end of the file. --> <!-- The following public character entity sets can be used to specify special characters in characteristic values of type "string".--> <!ENTITY % ISOlat1 PUBLIC "ISO 8879:1986//ENTITIES Added Latin 1//EN"> <!ENTITY % ISOpub PUBLIC "ISO 8879:1986//ENTITIES Publishing//EN"> <!ENTITY % ISOgrk3 PUBLIC "ISO 8879:1986//ENTITIES Greek Symbols//EN"> <!ENTITY % ISOnum PUBLIC "ISO 8879:1986//ENTITIES Numeric and Special Graphic//EN"> <!ENTITY % ISOtech PUBLIC "ISO 8879:1986//ENTITIES General Technical//EN"> %ISOlat1; %ISOpub; %ISOgrk3; %ISOnum; %ISOtech; <!ENTITY % yesorno "NUMBER" > <!NOTATION dummy SYSTEM "Dummy notation"> <!NOTATION cgm PUBLIC "-//USA-DOD//NOTATION Computer Metafile//EN"> <!ENTITY null SYSTEM "" NDATA dummy -- used for pointer values --> <!-- An output spec is made up of sections describing layout characteristics for page models, and style characteristics for graphics, tables, and all other elements. Fosicite is optionally available to identify the FOSI --> <!ELEMENT outspec - o (rsrcdesc?, secdesc?, pagedesc, styldesc, tabdesc?, grphdesc?, ftndesc?)> <!ATTLIST outspec fosicite CDATA -- a string -- #IMPLIED> <!-- This resource description section gives document-wide hyphenation rules as well as descriptions of character fills and counters that will be used throughout the FOSI. --> <!ELEMENT rsrcdesc - o (hyphrule*, charfill*, counter*, stringdecl*, floatloc*)> <!ELEMENT hyphrule - o EMPTY > <!ATTLIST hyphrule language ID -- an id -- #REQUIRED hjdata ENTITY -- a pointer -- #IMPLIED wordbrk ENTITY -- a pointer -- #IMPLIED unbrkwrd ENTITY -- a pointer -- #IMPLIED brkchars CDATA -- a string -- #IMPLIED brkbfchr CDATA -- a string -- #IMPLIED brkafchr CDATA -- a string -- #IMPLIED nobrkchr CDATA -- a string -- #IMPLIED type (dict | logic | both | any) #IMPLIED zone CDATA -- a size -- #IMPLIED ladder NUMBER -- an integer -- #IMPLIED minleft NUMBER -- an integer -- #IMPLIED minpush NUMBER -- an integer -- #IMPLIED clbrkok %yesorno -- toggle -- #IMPLIED pgbrkok %yesorno -- toggle -- #IMPLIED > <!ELEMENT charfill - o EMPTY> <!ATTLIST charfill literal CDATA -- a string -- #IMPLIED orient (vert | horiz) #IMPLIED type (rr | rf | ff | fr) #IMPLIED spbefore CDATA -- a size -- #IMPLIED spafter CDATA -- a size -- #IMPLIED padding CDATA -- a size -- #IMPLIED truncat %yesorno -- a toggle -- #IMPLIED suppress NUMBER -- integer -- #IMPLIED align %yesorno -- toggle -- #IMPLIED cfid ID -- an id -- #REQUIRED> <!ELEMENT counter - o EMPTY> <!ATTLIST counter initial CDATA -- A size -- #IMPLIED style (arabic | romanuc | romanlc | alphauc | alphalc | userdef) #IMPLIED specstyl CDATA -- a string -- #IMPLIED seq (1 | 2) #IMPLIED padlen NUMBER -- an integer-- #IMPLIED except CDATA -- a string -- #IMPLIED enumid ID -- an id -- #REQUIRED> <!ELEMENT stringdecl - o EMPTY> <!ATTLIST stringdecl textid NMTOKEN -- an id -- #REQUIRED literal CDATA -- a string -- #IMPLIED status %yesorno -- a toggle -- #IMPLIED scope NAME -- a name of an element -- #IMPLIED> <!ELEMENT floatloc - o EMPTY> <!ATTLIST floatloc floatid ID -- id of this location -- #REQUIRED floattyp ( once | atpgbrk | atcolbrk | multiref ) #IMPLIED maxdepth CDATA -- a dimension -- #IMPLIED minspace CDATA -- a dimension -- #IMPLIED nomspace CDATA -- a dimension -- #IMPLIED maxspace CDATA -- a dimension -- #IMPLIED> <!-- This section describes the priority ordering of security values, which are placed in header and footer areas. --> <!ELEMENT secdesc - o (sectoken+)> <!ATTLIST secdesc attspec NAMES #REQUIRED secorder NMTOKENS #IMPLIED ignoresec CDATA #IMPLIED> <!ELEMENT sectoken - o EMPTY> <!ATTLIST sectoken secval NMTOKEN #REQUIRED sectext CDATA #IMPLIED> <!-- This section describes the layout geometry of pages. Multiple descriptions can be set up and referenced through the id associated with the page model. --> <!ELEMENT pagedesc - o (pageset)+> <!ELEMENT pageset - o (rectopg, versopg?, rectobb?, versobf?, blankpg?)+> <!ATTLIST pageset id ID -- an id -- #REQUIRED rectver %yesorno -- toggle -- "1" blankpg %yesorno -- toggle -- "1" orient (portrait | landscape) "portrait"> <!ELEMENT (rectopg | versopg) - o (pageres?, (pagespec | (pageref, header?, footer?))) -(span)> <!ELEMENT blankpg - o (pageres?, (pagespec | (pageref, header?, footer?)), (puttext | usetext | putgraph | ruling)*) -(span)> <!ATTLIST (rectopg | versopg | blankpg) width NUTOKEN -- a size -- #IMPLIED nomdepth NUTOKEN -- a size -- #IMPLIED bind (lleft | ttop | bbottom) "lleft" chgmkwid NUTOKEN -- a size -- #IMPLIED chgmkoff NUTOKEN -- a size -- #IMPLIED chgmkplc (pleft | pright | pin | pout | plftrt) "pleft" topfloat IDREFS --idrefs of floatlocs-- #IMPLIED botfloat IDREFS --idrefs of floatlocs-- #IMPLIED> <!ELEMENT (rectobb | versobf) - o (pageres?, header?, footer?) -(span)> <!ELEMENT pageres - o (enumerat | savetext)*> <!ELEMENT pagespec - o (topmarg, botmarg, leftmarg, rtmarg, header, footer, flowtext+, bordspec*)> <!ATTLIST pagespec pgid ID #IMPLIED> <!ELEMENT pageref - o EMPTY> <!ATTLIST pageref pgidref IDREF -- reference to pgid -- #IMPLIED> <!ELEMENT topmarg - o EMPTY> <!ATTLIST topmarg nomdepth CDATA -- a size -- #IMPLIED> <!ELEMENT botmarg - o EMPTY> <!ATTLIST botmarg nomdepth CDATA -- a size -- #IMPLIED> <!ELEMENT leftmarg - o EMPTY> <!ATTLIST leftmarg width CDATA -- a size -- #IMPLIED> <!ELEMENT rtmarg - o EMPTY> <!ATTLIST rtmarg width CDATA -- a size -- #IMPLIED> <!ELEMENT (header | footer) - o (vquad | sectext | ruling | puttext | putgraph | usetext)* > <!ATTLIST (header | footer) nomdepth CDATA -- a size -- #IMPLIED maxdepth CDATA -- a size -- #IMPLIED spaflow CDATA -- a size -- #IMPLIED> <!ELEMENT sectext - o (subchars) +(vquad)> <!ATTLIST sectext scope (page | sheet | document) #IMPLIED> <!ELEMENT vquad - o EMPTY> <!ATTLIST vquad verquad (top | middle | bottom) #IMPLIED> <!ELEMENT flowtext - o (column, presp?, postsp?, gutter?, footnote?)> <!ATTLIST flowtext numcols (1 | 2 | 3 | 4 | 5 ) #IMPLIED balance %yesorno -- toggle -- #IMPLIED topfloat IDREFS --idrefs of floatlocs-- #IMPLIED botfloat IDREFS --idrefs of floatlocs-- #IMPLIED chgmkplc (pleft | pright | pin | pout | plftrt) #IMPLIED> <!ELEMENT column - o EMPTY> <!ATTLIST column width CDATA -- a size -- #IMPLIED tolerance CDATA -- a size -- #IMPLIED vjprior (col | comp) "col" topfloat IDREFS --idrefs of floatlocs -- #IMPLIED botfloat IDREFS --idrefs of floatlocs -- #IMPLIED> <!ELEMENT gutter - o EMPTY> <!ATTLIST gutter rlthick CDATA -- a size -- #IMPLIED ruleclr (black | white | red | orange | yellow | green | blue | violet | brown | gray) #IMPLIED rulepct NUMBER -- an integer -- #IMPLIED> <!ELEMENT footnote - o (subchars?)> <!ATTLIST footnote width (col, flowtext) "col" maxdepth CDATA -- a size -- #IMPLIED ftnsepth CDATA -- a size -- #IMPLIED ftnsepln CDATA -- a size -- #IMPLIED ftnbrk %yesorno -- a toggle -- "1" ftncntsp CDATA -- a size -- #IMPLIED ftnconsl CDATA -- a size -- #IMPLIED ftnconst CDATA -- continue string -- #IMPLIED spabove CDATA -- a size -- #IMPLIED ftnfloat %yesorno -- a toggle -- "0"> <!ELEMENT bordspec - o EMPTY> <!ATTLIST bordspec bordname NMTOKEN #REQUIRED bordent ENTITY #REQUIRED> <!-- This section describes the style characteristics associated with all elements that are not a graphic or table. --> <!ELEMENT styldesc - o (charsubset*, docdesc, envdesc*, e-i-c+)> <!ELEMENT docdesc - o (charlist) -(subchars)> <!ELEMENT envdesc - o (charlist) -(subchars)> <!ATTLIST envdesc envid ID #REQUIRED> <!ELEMENT e-i-c - o (charlist, att*)> <!ATTLIST e-i-c gi NAMES --a list of generic identifiers-- #REQUIRED context CDATA -- see Context Syntax -- #IMPLIED occur (only | first | last | middle | notlast | notfirst | all) "all"> <!ELEMENT charsubset - o (font?, leading?, hyphen?, wordsp?, lettersp?, indent?, quadding?, highlt?, chgmark?, presp?, postsp?, keeps?, vjinfo?, textbrk?, span?, border?, float?, algroup?, suppress?, boxing?, tabatts?, tgroupatts?, colatts*, subsetatts?, rowatts?, cellatts?, reset?, (enumerat | savetext | ruling | puttext | putgraph | usetext)*)> <!ATTLIST charsubset charsubsetid ID #IMPLIED charsubsetref IDREFS --list of referenced charsubset IDs-- #IMPLIED > <!ELEMENT charlist - o (font?, leading?, hyphen?, wordsp?, lettersp?, indent?, quadding?, highlt?, chgmark?, presp?, postsp?, keeps?, vjinfo?, textbrk?, span?, border?, float?, algroup?, suppress?, boxing?, tabatts?, tgroupatts?, colatts*, subsetatts?, rowatts?, cellatts?, reset?, (ruling | enumerat | puttext | putgraph | savetext | usetext)*)> <!ATTLIST charlist envname IDREF -- reference to envid -- #IMPLIED inherit %yesorno "0" charsubsetref IDREFS -- list of referenced charsubset IDs -- #IMPLIED > <!ELEMENT att - - ((specval | fillval)+, charsubset?)> <!ATTLIST att logic (and | or) 'and' > <!ELEMENT specval - o EMPTY> <!ATTLIST specval attname NAME #REQUIRED attloc CDATA #IMPLIED attval CDATA #REQUIRED> <!ELEMENT fillval - o EMPTY > <!ATTLIST fillval attname NAME #REQUIRED attloc CDATA #IMPLIED fillcat CDATA #REQUIRED fillchar CDATA #REQUIRED conrule CDATA #IMPLIED> <!ELEMENT font - o EMPTY> <!ATTLIST font inherit %yesorno -- toggle -- #IMPLIED style (serif | sanserif | monoser | monosans) #IMPLIED famname CDATA -- a font name -- #IMPLIED size CDATA -- a size -- #IMPLIED posture (upright | oblique | bsobl | italic | bsital) #IMPLIED weight (ultlight | exlight | light | semlight | medium | sembold | bold | exbold | ultbold) #IMPLIED width (ultcond | excond | cond | semcond | regular | semexp | exp | exexp | ultexp) #IMPLIED smallcap %yesorno -- toggle -- #IMPLIED offset CDATA -- size -- #IMPLIED > <!ELEMENT leading - o EMPTY> <!ATTLIST leading inherit %yesorno -- toggle -- #IMPLIED lead CDATA -- a size -- #IMPLIED force %yesorno -- a toggle -- #IMPLIED> <!ELEMENT hyphen - o EMPTY> <!ATTLIST hyphen inherit %yesorno -- toggle -- #IMPLIED lang IDREF -- reference to a hyphrule language -- #IMPLIED hyph %yesorno -- toggle -- #IMPLIED zone CDATA -- a size -- #IMPLIED> <!ELEMENT wordsp - o EMPTY> <!ATTLIST wordsp inherit %yesorno -- toggle -- #IMPLIED minimum CDATA -- a size -- #IMPLIED nominal CDATA -- a size -- #IMPLIED maximum CDATA -- a size -- #IMPLIED> <!ELEMENT lettersp - o EMPTY> <!ATTLIST lettersp inherit %yesorno -- toggle -- #IMPLIED minimum CDATA -- a size -- #IMPLIED nominal CDATA -- a size -- #IMPLIED maximum CDATA -- a size -- #IMPLIED kerntype (none | pair | track | sector | pairtrk | trksectr) #IMPLIED kernpair ENTITY -- pointer -- #IMPLIED> <!ELEMENT indent - o EMPTY> <!ATTLIST indent inherit %yesorno -- toggle -- #IMPLIED leftind CDATA --see Indent Syntax -- #IMPLIED rightind CDATA --see Indent Syntax -- #IMPLIED firstln CDATA --see Indent Syntax -- #IMPLIED> <!ELEMENT quadding - o EMPTY> <!ATTLIST quadding inherit %yesorno -- toggle -- #IMPLIED quad (right | left | center | in | out | justify | asis) #IMPLIED lastquad (lright | lleft | lcenter | lin | lout | ljustify | relative) #IMPLIED> <!ELEMENT highlt - o EMPTY> <!ATTLIST highlt inherit %yesorno -- toggle -- #IMPLIED reverse %yesorno -- toggle -- #IMPLIED scoring NUMBER -- an integer -- #IMPLIED scorewt CDATA -- a size -- #IMPLIED scoreoff CDATA -- a size -- #IMPLIED scorechron %yesorno -- toggle-- #IMPLIED scorechr CDATA -- a string -- #IMPLIED bckclr (bblack | bwhite | bred | borange | byellow | bgreen | bblue | bviolet | bbrown | bgray) #IMPLIED fontclr (black | white | red | orange | yellow | green | blue | violet | brown | gray) #IMPLIED bckpct NUMBER -- an integer -- #IMPLIED forpct NUMBER -- an integer -- #IMPLIED allcap %yesorno -- toggle -- #IMPLIED scorespc %yesorno -- toggle -- #IMPLIED> <!ELEMENT chgmark - - (font?, indent?, quadding?, highlt?)> <!ATTLIST chgmark literal CDATA -- a string -- #IMPLIED barthick CDATA -- a size -- #IMPLIED join %yesorno -- a toggle -- #IMPLIED type (content | start | end) #IMPLIED> <!ELEMENT (presp | postsp) - o EMPTY> <!ATTLIST (presp | postsp) minimum CDATA -- a size -- #IMPLIED nominal CDATA -- a size -- #IMPLIED maximum CDATA -- a size -- #IMPLIED condit (keep | discard) #IMPLIED priority (force | high | med | low | none) #IMPLIED> <!ELEMENT keeps - o EMPTY> <!ATTLIST keeps inherit %yesorno -- toggle -- #IMPLIED keep %yesorno --toggle -- #IMPLIED scope (col | page | line) #IMPLIED widowct NUMBER -- an integer -- #IMPLIED orphanct NUMBER -- an integer -- #IMPLIED next %yesorno -- toggle -- #IMPLIED prev %yesorno -- toggle -- #IMPLIED floatsout IDREFS --idrefs of floatlocs -- #IMPLIED> <!ELEMENT vjinfo - o EMPTY> <!ATTLIST vjinfo inherit %yesorno -- toggle -- #IMPLIED presppr (force | high | med | low | none) #IMPLIED postsppr (pforce | phigh | pmed | plow | pnone) #IMPLIED keepspr (kforce | khigh | kmed | klow | knone) #IMPLIED > <!ELEMENT textbrk - o EMPTY> <!ATTLIST textbrk startcol %yesorno -- toggle -- #IMPLIED startpg (off | verso | recto | next | versoblank | rectoblank) #IMPLIED pageid IDREF -- reference to pageset id -- #IMPLIED newpgmdl (none | global | local) #IMPLIED startln %yesorno -- toggle -- #IMPLIED endln %yesorno -- toggle -- #IMPLIED> <!ELEMENT span - o EMPTY> <!ATTLIST span span NUMBER -- an integer -- #IMPLIED> <!ELEMENT border - o EMPTY> <!ATTLIST border bordname NMTOKEN -- a border name defined in bordspec -- #IMPLIED> <!ELEMENT float - o EMPTY> <!ATTLIST float flidref IDREF -- id of a float location -- #IMPLIED width ( page | col ) #IMPLIED scope NAMES -- names of elements -- #IMPLIED pagetype (same | facing | frontback | next | forward | afterref | inline) #IMPLIED multirefname NMTOKEN -- any token -- #IMPLIED > <!ELEMENT algroup - o EMPTY> <!ATTLIST algroup refpoint (top, first, middle, last, bottom) #IMPLIED postspace %yesorno #IMPLIED> <!ELEMENT suppress - o EMPTY> <!ATTLIST suppress sup %yesorno --a toggle -- #IMPLIED children %yesorno --a toggle -- #IMPLIED> <!ELEMENT boxing - o EMPTY> <!ATTLIST boxing toffset CDATA -- a size -- #IMPLIED boffset CDATA -- a size -- #IMPLIED loffset CDATA -- a size -- #IMPLIED roffset CDATA -- a size -- #IMPLIED trel (top | first) #IMPLIED brel (last | bottom) #IMPLIED siderel (text | col | content) #IMPLIED leftgap CDATA -- a size -- #IMPLIED rightgap CDATA -- a size -- #IMPLIED thick CDATA -- a size -- #IMPLIED ttype (tblank | tsingle | tbold | tdouble | ttriple | tdot | tdash) #IMPLIED btype (bblank | bsingle | bbold | bdouble | btriple | bdot | bdash) #IMPLIED ltype (lblank | lsingle | lbold | ldouble | ltriple | ldot | ldash) #IMPLIED rtype (rblank | rsingle | rbold | rdouble | rtriple | rdot | rdash) #IMPLIED inclr (iblack | iwhite | ired | iorange | iyellow | igreen | iblue | iviolet | ibrown | igray) #IMPLIED inpct NUMBER -- an integer -- #IMPLIED outclr (black | white | red | orange | yellow | green | blue | violet | brown | gray) #IMPLIED outpct NUMBER -- an integer -- #IMPLIED> <!ELEMENT reset - o EMPTY> <!ATTLIST reset resetlist NMTOKENS --list of ids of variables to be reset-- #IMPLIED> <!ELEMENT ruling - - (leading?, indent?, quadding?, presp?, postsp?, keeps?, textbrk?, span?)> <!ATTLIST ruling thick CDATA -- a size -- #IMPLIED lentype (rel | spec) #IMPLIED speclen CDATA -- a size -- #IMPLIED rellen (text | col) #IMPLIED voffset CDATA -- a size -- #IMPLIED placemnt (before | after) #IMPLIED ruleclr (black | white | red | orange | yellow | green | blue | violet | brown | gray) #IMPLIED rulepct NUMBER -- an integer -- #IMPLIED type (blank | single | bold | double | triple | dot | dash) #IMPLIED> <!ELEMENT enumerat - o EMPTY> <!ATTLIST enumerat increm CDATA -- a size -- #IMPLIED enumid IDREF -- an idref -- #IMPLIED setvalue %yesorno -- a toggle -- #IMPLIED> <!ELEMENT puttext - - (subchars?)> <!ATTLIST puttext literal CDATA -- a string -- #IMPLIED placemnt (before | after) #IMPLIED> <!ELEMENT putgraph - - (subchars?)> <!ATTLIST putgraph graphname ENTITY -- an entity reference -- #REQUIRED width CDATA -- a size -- #IMPLIED depth CDATA -- a size -- #IMPLIED placemnt (before | after) #IMPLIED scalefit %yesorno --a toggle -- #IMPLIED hscale NUMBER -- an integer -- #IMPLIED vscale NUMBER -- an integer -- #IMPLIED hoffset CDATA -- a size -- #IMPLIED voffset CDATA -- a size -- #IMPLIED rotation %yesorno -- a toggle -- #IMPLIED> <!ELEMENT savetext - o EMPTY> <!ATTLIST savetext textid NMTOKEN -- an id -- #IMPLIED conrule CDATA -- a string -- #IMPLIED placemnt (before | after) #IMPLIED append %yesorno -- a toggle -- #IMPLIED startpos NUMBER -- an integer -- #IMPLIED endpos NUMBER -- an integer -- #IMPLIED delim CDATA -- a string -- #IMPLIED occur NUMBER -- an integer -- #IMPLIED> <!ELEMENT usetext - - (subchars?)> <!ATTLIST usetext source CDATA -- a string -- #IMPLIED placemnt (before | after) #IMPLIED userule NMTOKEN --attribute -- #IMPLIED useparam CDATA --a string -- #IMPLIED> <!ELEMENT subchars - o (font?, leading?, hyphen?, wordsp?, lettersp?, indent?, quadding?, highlt?, chgmark?, presp?, postsp?, keeps?, vjinfo?, textbrk?, span?, border?, float?, algroup?, boxing?, tabatts?, tgroupatts?, colatts*, subsetatts?, rowatts?, cellatts?, reset?, (enumerat | savetext | ruling)*)> <!ATTLIST subchars charsubsetref IDREFS --list of referenced charsubset IDs-- #IMPLIED > <!-- This section describes the characteristics associated with a table. --> <!ELEMENT tabdesc - o (e-i-c+)> <!ELEMENT tabatts - o (stdcellatts?)> <!ATTLIST tabatts widthtype (specific | relative) #IMPLIED specwidth CDATA -- a size -- #IMPLIED relwidth CDATA -- a percentage -- #IMPLIED frame (all | top | bottom | topbot | sides | none) #IMPLIED thick NUTOKEN -- a size -- #IMPLIED framestyle (blank | single | bold | double | triple | dot | dash) #IMPLIED consep %yesorno -- toggle -- #IMPLIED> <!ELEMENT stdcellatts - o EMPTY> <!ATTLIST stdcellatts colsepon %yesorno -- toggle -- #IMPLIED rowsepon %yesorno -- toggle -- #IMPLIED colsep NUTOKEN -- a size -- #IMPLIED rowsep NUTOKEN -- a size -- #IMPLIED colsepstyle (cblank | csingle | cbold | cdouble | ctriple | cdot | cdash) #IMPLIED rowsepstyle (rblank | rsingle | rbold | rdouble | rtriple | rdot | rdash) #IMPLIED leftmar NUTOKEN -- a size -- #IMPLIED rightmar NUTOKEN -- a size -- #IMPLIED topmar NUTOKEN -- a size -- #IMPLIED botmar NUTOKEN -- a size -- #IMPLIED halign (right | left | center | justify | char) #IMPLIED valign (top | middle | bottom) #IMPLIED char CDATA -- see source syntax -- #IMPLIED charoff NUTOKEN -- a percentage -- #IMPLIED reverse %yesorno -- toggle -- #IMPLIED bckclr (black | white | red | orange | yellow | green | blue | violet | brown | gray) #IMPLIED shading NUMBER -- a percentage -- #IMPLIED rotate %yesorno -- a toggle -- #IMPLIED textwidth NUTOKEN -- a size -- #IMPLIED brkrow %yesorno -- toggle -- #IMPLIED celconflict (error | append | newrow) #IMPLIED> <!ELEMENT tgroupatts - o (stdcellatts?)> <!ATTLIST tgroupatts cols NUTOKEN -- integer -- #IMPLIED> <!ELEMENT subsetatts - o (stdcellatts?)> <!ATTLIST subsetatts cols NUMBER -- number -- #IMPLIED keep (col | page | none) #IMPLIED subsettype (head | body | foot) #IMPLIED> <!ELEMENT colatts - o (stdcellatts?)> <!ATTLIST colatts colnum CDATA -- a string -- #IMPLIED colname NMTOKEN -- an id -- #IMPLIED colwidth CDATA -- see column width syntax -- #IMPLIED spanname NMTOKEN -- a name token -- #IMPLIED namest NMTOKEN -- a name token -- #IMPLIED nameend NMTOKEN -- a name token -- #IMPLIED> <!ELEMENT rowatts - o (stdcellatts?)> <!ATTLIST rowatts brkrow %yesorno -- toggle -- "0"> <!ELEMENT cellatts - o (stdcellatts?)> <!ATTLIST cellatts colname NMTOKEN -- a name token -- #IMPLIED spanname NMTOKEN -- a name token -- #IMPLIED spandep NUMBER -- integer -- #IMPLIED> <!-- This section describes the characteristics associated with a graphic inside a figure. --> <!ELEMENT grphdesc - o (graphenv+, graphe-i-c+)> <!ELEMENT graphenv - o (graphchars)> <!ATTLIST graphenv graphenvid ID -- an id -- #IMPLIED> <!ELEMENT graphe-i-c - o (e-i-c, (graphchars, gatt*)?)> <!-- Note that for text block graphic objects, the charlist on the e-i-c applies to composition of the text within the text block bounding box. --> <!ELEMENT graphchars - o (repro?, ((sizing, placemnt) | (textblock, placemnt))?)> <!-- Note that to achieve multiple graphic objects in a single reproduction area, no repro characteristics are specified and the repro area of an ancestor of the graphic object is used. --> <!ATTLIST graphchars envname IDREF -- reference to graphenvid -- #IMPLIED> <!ELEMENT repro - o EMPTY> <!ATTLIST repro reprowid CDATA -- size -- #IMPLIED reprodep CDATA -- size -- #IMPLIED> <!ELEMENT sizing - o EMPTY> <!ATTLIST sizing graphname ENTITY -- a pointer -- #IMPLIED hscale NUMBER -- integer -- #IMPLIED vscale NUMBER -- integer -- #IMPLIED scalefit %yesorno -- toggle -- #IMPLIED llcordra CDATA -- a string of world coordinates -- #IMPLIED urcordra CDATA -- a string of world coordinates -- #IMPLIED> <!ELEMENT textblock - o EMPTY> <!ATTLIST textblock tbwidth CDATA -- size -- #IMPLIED tbdepth CDATA -- size -- #IMPLIED horrefpt (left | right) #IMPLIED verrefpt (top | bottom) #IMPLIED> <!-- Generally, the tbdepth would be omitted which would imply that the textblock would have a depth that varies according to the content (much like table cells generally work). Note that the content of the e-i-c instance for text block graphic objects becomes the textual content of the textblock object. --> <!ELEMENT placemnt - o EMPTY> <!ATTLIST placemnt hplace (left | center | right | hnone) #IMPLIED vrplace (top | middle | bottom | none) #IMPLIED coordst CDATA -- a string of world coordinates-- #IMPLIED coordend CDATA -- a string of world coordinates-- #IMPLIED rotation %yesorno -- toggle -- "0"> <!-- Note that coordend is ignored for textblocks --> <!ELEMENT gatt - o ((specval | fillval)+, graphchars?)> <!ATTLIST gatt logic (and | or) 'and' > <!-- Note that charlist is not needed here as it applies only to text block graphic objects and are handled within the e-i-c portion of the graphe-i-c. --> <!-- This section describes the characteristics associated with elements to be placed in the footnote area. --> <!ELEMENT ftndesc - o (e-i-c, ftnatts)*> <!ELEMENT ftnatts - o (charlist) -(keeps,span)> 60. GUIDELINES 60.1 Introduction. This section provides additional material to be used by those creating a FOSI or altering an existing one. This material is supplemental only; in order to create or modify a FOSI, the author must have a good working knowledge of sections 10 through 40 of this appendix. Ideally, a FOSI author has a background in typographic design and has a working knowledge of SGML. The most important qualification, however, is intimate familiarity with the requirements of the functional specification that are to be represented through the FOSI. The following subsections describe a typical approach to creating or modifying a FOSI. Within each step of the approach, techniques for applying specific OS concepts are discussed. In addition, relevance of OS concepts to particular element types within the template DTD of appendix A are noted. The novice FOSI author may find it useful to read this entire section in order to get an idea of the topics discussed. To help the reader relate constructs and characteristics to their actual encoding specified in section 40, the names appearing in the DTD may also follow in parenthesis (generally shortened versions). In referring to values of characteristics of type "toggle", the phrases "turned on" and "turned off" are used to mean non-zero and zero, respectively. 60.2 Step 1 - Understanding the requirements. The first step in creating a FOSI is understanding the requirements for the structure and formatting of the documents to be interchanged. The information about the structure of the document should already be rigorously described in a DTD. The DTD defines the element types, the possible structure the document can have using these element types, and the attributes that can be associated with each element type. Ideally, there is supporting documentation to describe the meaning and usage of each element type and its attributes, although if such documentation is not available, the burden may fall upon the FOSI author to determine this information from the original functional specification. Formatting information may be contained in a single functional specification or may appear in a combination of specifications. Again, the burden may fall upon the FOSI author to determine how the formatting information in the specifications relates to the element types defined in the DTD. In addition, the FOSI author must identify all relevant formatting information in the specifications that must be included in the FOSI. There may be cases where an organization uses formatting practices in addition to or in place of formatting guidelines in the functional specifications. These "common practices" have been indirectly approved because of acceptance of delivered documents using these practices. An example is the common use of kerning in documents conforming to MIL-M-38784, where kerning is not mentioned in the specification. The FOSI author must be aware of these "common practices", typically documented in the organization's style guidelines, so that all the relevant formatting information is included in the FOSI. 60.3 Step 2 - Understanding OS concepts. The FOSI author must be aware of some underlying principles of the OS in order to correctly communicate the formatting information. Following is a discussion of these basic principles. 60.3.1 Intent of a FOSI. A FOSI is intended to specify, in general, how a particular class of documents should be formatted. It does not specify how any particular document was actually formatted; this appendix is not precise or robust enough to provide all the necessary information. Characteristics are, in general, descriptions of the format of a document, rather than commands that tell a formatting system what to do. For example, if a FOSI has a value of "10" for the Font Size Characteristic for element type "A", this should be interpreted as: "However your formatting system works, make sure that font size 10 is used to process element 'A'." The FOSI should not be interpreted as saying "When you see a start-tag for element 'A' call a command that changes the font size and give it a value of 10". This is a subtle, but extremely important, distinction. The first interpretation allows any system (including a human) to create the desired end result, while the second interpretation allows for only systems with a specific command language to easily create the desired result. In this way, the OS does not presume to direct how a formatting system should behave in order to accomplish the desired result. 60.3.2 Identification and treatment of source data. The basic unit of data within the source document identified within a FOSI is an element (qualified by its context and occurrence). Additionally, attribute values associated with the element can be identified. Once identified, an element is treated as whole. The characteristics associated with the element through the FOSI apply to all the content of that element. There is no notion of "start-tag" and "end-tag" processing. In general, it is safe to think of the characteristics as "going into effect" as soon as processing of the element's content begins. Some characteristics, however, are designed to take affect "after" the element content has been processed and are so identified in this specification. An example is the "End Line" characteristic. In addition, some characteristics specify whether other characteristics take effect "before" or "after" the element content is processed, for example, the Placement characteristic of the Puttext, Putgraph, and Usetext categories. 60.3.3 Cognizance of source DTD. Every relevant element and attribute in the source DTD should have an entry in the FOSI describing how it is to be formatted. In processing a FOSI, there should be no assumptions made about the source data. For example, an element type of "ftnote" cannot be assumed to be a footnote. It must be identified as a footnote by positioning its description in the proper structure of the FOSI (the "ftndesc"). A footnote can have the element type "xyz" in the source DTD, but as long as it is described in the "ftndesc" of the FOSI, it will be treated as a footnote. Similarly, all attributes that affect formatting must be identified in the FOSI. 60.4 Step 3 - Organizing and documenting a FOSI. 60.4.1 Technique - Order of elements-in-context in the FOSI. The order of the e-i-cs within the style, table, graphics, or footnote descriptions have no bearing on how the element is formatted. Some sensible ordering scheme is useful, however, for human readability and access. Ordering the e-i-cs to match the order of element types in the source DTD may be a good choice, as the reader of the FOSI is most likely familiar with the source DTD. Typically, the source DTD reflects the structure of the document and provides a progression from "structural"-type elements (chapters and sections) through "paragraph"-type elements (title and para) down to "inline"-type elements (emphasis). If the source DTD does not provide this type of ordering, it may be useful to group FOSI entries into these types of functional areas as they may share common types of descriptions. 60.4.2 Technique - Documenting a FOSI. It is good practice to include comments within a FOSI to explain techniques used. Comments cannot be used in place of encoding information through characteristics, but they can help the reader understand the intent of a particular encoding. Comments are preceded by the string "<!--" and followed by the string "-->". They can be placed between any elements in the FOSI but not within tag delimiters. 60.5 Step 4 - Setting up the resource description. The Resource Description gives document-wide Hyphenation Rules, as well as descriptions of Character Fills, Counters, Strings, and Floats that will be used throughout the FOSI. The Hyphenation Rule category provides for setting various parameters for the hyphenation process that will be used throughout the document. The Character Fill category provides for describing literals that can be used to fill a space horizontally or vertically (see 60.12.19). The Counter construct is used in the Resource Description to specify the properties of a counter that will be associated with one or more e-i-cs using the Enumerate category (see 60.12.20). The String construct is used in the resource description to specify the properties of a text variable that will be associated with one or more e-i-cs using the savetext or usetext characteristic (see also 60.12.24 and 60.12.25). The float construct is used in the resource description to specify that an e-i-c's contents should float to some other place in the ouput instance than the next available location in the flowing text area. 60.6 Step 5 - Setting up the security description. In the Security Description, the strings are established to be automatically generated for the "security text" identified in the header and footer. To set up these strings, the possible values for the attribute in the source DTD that indicates security must be known. First, identify the name of the attribute in the source that indicates security levels with the "attspec" characteristic. Then, through the Secorder, indicate the priority of its values. This priority is used when computing the value that is to appear in the header or footer. Then, set up the string that is to appear for each value. Style and positioning characteristics are specified for the string through the "sectext" portion of the header and footer specification. 60.7 Step 6 - Setting up page models. A description of how the pages are to look (the page model) can be set up independently of the content that goes on them. The areas in which content is to be placed and its placement and relationship are defined in section 40.4. Using Figure 2 in 40.4.2.1 as a guide, the FOSI author must analyze the formatting specifications for page layout to determine the sizes of these areas and specify the characteristics that control how and when these areas are created on the page. 60.7.1 Technique - Using page sets. Page sets provide the means to specify automatic relationships between recto, verso, recto pages with blank backs, verso pages with blank fronts, and automatically generated blank pages. Typically, these relationships are useful when the document is to be printed "two-sided" in a book style. Each page layout can be described individually, but when only the recto page is described, all pages have the same layout. By turning on the Recto/Verso toggle, inner and outer margins are automatically reversed on recto and verso pages, usually to allow a wider margin for the bind edge. By turning on the Blank Page toggle, special actions can be taken when a blank page is automatically generated, for example, when the text for a new chapter starts on a recto page and the text for the previous chapter ends on a recto page. 60.7.2 Technique - Setting page parameters. The layout areas within the page can be thought of as a set of building blocks that must fit together. Because their relationships are defined in the OS (refer see 30.2.2 ), it is the responsibility of the FOSI author to ensure that the sizes specified are valid. One approach to defining the sizes of layout areas is to first define the width and depth of the page. Then define the widths of areas. The left and right margin widths are defined first and the flow text is computed by taking the difference of the page width and the left and right margins. If only one column exists within the flowing text area, it's width will be equal to that of the flowing text area. When more than one column exists, the width of each column is the same. The gutter area width will be the area remaining between cumulative column width and the widyh of the flowtext areas. If more than two columns exist, the gutter widths are the same. Now determine the depths. Choose the most important parmeter and work from there. For example, given the depth of the top and botton margins, determine appropriate minimum, nominal and maximum depths for headers and footers. Keep in mind that some header and footer information may be determined by the actual content of the page. The difference between the depth of the page and the top and bottom margins, header and footer nominal depths and the appropriate space above and space below flowtext, is the depth of the flowtext area. The Change Mark Area can be thought of as "overlaid" on the Margins; its width and depth are specified independently of other size computations. 60.7.3 Technique - Using page references. Page references are a shortcut for specifying a page model when the only difference from another page model is the header and footer information. Each page model can be assigned a unique identifier through the "pgid" attribute. A page reference then refers to this page model through the "pgidref" attribute and any header and footer information additionally supplied overrides the header and footer information in the referenced page model. If no header and footer information is supplied, the page model uses the header and footer information contained in the referenced page model. 60.7.4 Technique - Setting up headers and footers. Headers and footers typically contain text that is dependent on document content, such as the technical manual identification number and the chapter title. To specify text dependent on document content, use Usetext, making sure to specify Savetext on the appropriate e-i-c. The headers and footers may be specified to allow variable depth. 60.7.4.1 Positioning techniques. The style and positioning of text placed in the header and footers is determined by the Subcharacteristics (subchar) specified for Puttext and Usetext and the Vertical Quadding (vquad) additionally specified within the header or footer. For simple cases, where the text is anticipated to be a single line, use the Quadding values "right", "left", "center", "in", and "out" for horizontal positioning and the Vertical Quadding values of "top", "middle", and "bottom" for vertical positioning. This allows for nine positions relative to the Header or Footer Area. Note that "vquad" is an inclusion to the content model of the header and footer. This allows it to be placed anywhere within the header and footer specification. When it appears within a Subcharacteristic list, it applies to the text specified by the Puttext or Usetext that is the parent of the list. When it appears outside the Subcharacteristic list, it applies to the text specified preceding the Puttext or Usetext. For more precise positioning and handling multiple-line text, form a "box" using Prespace Nominal to specify the distance from the top edge of the area, Postspace Nominal to specify the distance from the bottom edge of the area, Left Indent (leftind) to specify the distance from the left edge of the area, and Right Indent (rightind) to specify the distance from the right edge of the area. Quadding can then be used to specify how the lines are positioned within the box. 60.7.4.2 Using security values. Headers and footers may contain various types of security classifications, which may vary depending on the content of the page or sheet. This text is identified within the headers and footers as Security Text (sectext). This text is special because it is automatically generated based on the specifications within the Security Description (secdesc). a. In secdesc, define the attribute in the source document that identifies the security by using "attspec". Use "secorder" to list the priority, from highest to lowest, of the values to be found in the source document security attribute. b. Use sectoken as many times as required to give the possible source document attribute values and the security string to be associated with each specific value. c. In the header and footer, use sectext to set the scope for consideration when determining the highest security. The subcharacteristics specify the style and positioning of the resulting text in the same way as other header and footer text. 60.7.4.3 Using page numbers. To generate page numbers, set up an Enumerate specification, in the Page Resource (pageres). 60.7.5 Technique - Setting up footnote areas. In setting up the footnote area, choose whether the footnotes will appear at the bottom of each column or spanning the Flowing Text Area. Because the footnote area "grows upward", think of the "depth" as the "height". Specify the maximum amount of space that the footnotes can take up within the column and the fixed amount of space that should always appear between the text and the footnotes. Identify a rule separating the flowing text and footnotes by specifying its length and thickness. Specify whether footnotes can break across pages, and if so, specify what the rule and generated text look like (using subcharacteristics). Specify whether footnotes stay "attached" to the footer or the flowing text when a floating figure or table appears at the bottom of the page. See 60.16 for more discussion on describing footnotes. 60.7.6 Technique - Controlling floating elements. Table and figures can be thought of as "floating" elements because they may not appear in the resulting formatted document in exactly the same position as they occurred in the source document. In the source, tables and figures may have attributes specified that indicate they are "associated" with other source text. For example, a figure might be associated with a particular paragraph so that they can be kept together on the same page for nominal readability. (See 30.2.2) 60.8 Step 7 - Setting up the style description. After setting up the page models, specify formatting characteristics for every element that may appear in the document. One approach is to look at the formatting specification and determine the overall general requirements. These requirements can be specified for the document description, providing document-wide defaults. Then, look for common sets of requirements, specifying them as named environments, for example, for front, body, and rear matter. Next, consider each element type and the requirements that must be specified for each that are different from the document or environment specifications. Determine whether there are unique requirements for element types in specific contexts and specify e-i-cs for each. Finally, determine how attributes in the source affect formatting and further specify the characteristics to handle them. 60.9 Step 8 - Setting up the document default. Since the values specified for the document description supply the ultimate default values when characteristics are left unspecified, great care should be exercised in selecting these values and consideration must be given to the ramification of leaving any specific characteristic unspecified in the document description. For example, determine whether most elements begin on a new line or not. If Start Line (startln) on is the document default, be sure that, for those elements that do not start on a new line, startln is set to "off". Or, as the default, leave Start Line off and specifically turn it on for each relevant element. In general, choose defaults that will make the FOSI as brief as possible, yet allow an intuitive value to be specified for differing elements. (Certain values, such as that for letterspace or wordspace, may best be optimized by the output system.) 60.10 Step 9 - Setting up environments. Environments are useful when some set of characteristics is common to many elements. Environments can be referred to by any e-i-c and then only the differing characteristics for that e-i-c need to be specified. Care should be exercised in defining environments, using them to make the FOSI more brief and easier to comprehend. 60.11 Step 10 - Determining element categories. The first step in defining a specification for an element type is to determine the applicable functional area (see 40.1) under which the associated GI should be defined. All elements described in the Style Description (styldesc) are placed in the Flowing Text Area in the order in which they occur in the source document. All elements to be treated as tables must be described in the Table Description (tabdesc) and those to be treated as graphics in the Graphics Description (grphdesc). All elements to be treated as footnotes must be described in the Footnote Description (ftndesc) and are placed in the Footnote Area. 60.12 Step 11 - Describing elements. If document and environment defaults have already been established, describing elements is a matter of determining which characteristics differ from those defaults and thus need to be specified. 60.12.1 Technique - Grouping elements. When elements require the same set of characteristics and do not have unique contexts or attribute specifications, they can be grouped in a single FOSI entry. To group elements, specify the names in a list as the value for the "GI" of the e-i-c. 60.12.2 Technique - Using context and occurrence. Analysis of the source DTD and formatting requirements may reveal that the author of the source DTD has chosen to use a single element type to identify a piece of information, but that element type may be used in many "contexts" throughout the document. For example, "title" identifies a title, but when used within a "chapter", it identifies a chapter title, and when used within a "section", it identifies a section title. It must be determined when different formatting characteristics apply and specify an e-i-c for each. Be sure to analyze all levels of the document, especially areas where "structural" elements are optional. For example, a chapter may or may not have sections. Whether it actually does can have a profound impact on formatting, for example, numbering of paragraphs may be different. In these cases, it may be necessary to specify many lower-level elements twice: once in the context of "section" and once in the context of "chapter". Also, look carefully at elements that can appear in many places. For example, "para" can appear in any level of subparagraph or step. Adjust formatting characteristics for "para", such as indents, depending in which subparagraph or step it is found. 60.12.3 Technique - Using inheritance and defaulting. Inheritance and defaulting are the rules for determining the value of a characteristic when it is left unspecified for an e-i-c. For a discussion of these rules, refer to 30.3.4. The major consideration for choosing to use defaulting is brevity of the FOSI. Approaches to using defaulting have been discussed previously. In considering the use of inheritance, it is important to note that inheritance provides a dramatic reduction in the size of the FOSI for certain kinds of elements (e.g. wordsp and lettersp). For example, suppose that, for hypertext purposes, the "tool" element has been defined to identify information about a tool within a paragraph. In printed documents, this information should appear exactly the same as the rest of the paragraph text. By inheriting the paragraph characteristics, the tool text appears the same as the rest of the paragraph text. It is not necessary to predict every possible context for "tool" (there are thousands) in order to get the correct results. Note that inheritance specifies that characteristics are picked up from those in effect for the parent at the point in the document where the e-i-c occurs. The FOSI author can be aware of all the possible places an e-i-c can occur in a document by examining the source DTD, but the actual parent and characteristics in effect can be determined only by looking at the actual source document. Inheritance can provide very important relief from having to specify all possible contexts of an e-i-c. The material placed into the document by a Usetext may contain complete elements from the source document (for example, in-line textual elements contained within #CONTENTS of a Savetext string) as well as text. Both the text and the elements should determine their context and inheritance based on the environment into which the saved material is inserted by Usetext. That is, the parent for all text and elements within a Usetext fragment is the element instance whose e-i-c contains the Usetext; the rest of the ancestry of the contents of the Usetext would be the ancestry of this parent. This lineage not only determines the context for e-i-c computation but also forms the environment from which the formatting characteristics would be obtained. 60.12.4 Technique - Determining the font. There are two ways to specify the style of the font for text. Use Style to specify the general style of the font. Font styles are proportionally-spaced serif (serif), proportionally-spaced sans serif (sanserif), monospaced serif (monoser), and monospaced sans serif (monosans). In addition, it is possible to specify the name of an actual font, for example, "Century Textbook", which the formatting system can optionally select. To specify characteristics of the font, use Posture, Weight, and Proportionate Width. To specify the "normal" font, use the values "upright", "medium", and "regular", respectively. To specify the size of the font, supply a value for Size, typically in points. How the formatting system actually chooses an actual font is based on the algorithms within the system. While the specification describes font as a style modified by characteristics, it is common for font libraries to include different actual fonts for upright and italic versions. 60.12.5 Technique - Specifying leading. Leading is directly related to the font size. In this specification, leading is measured from text baseline to text baseline. Therefore the value for Lead should be at least as large as the value for the Font Size, and is typically slightly larger. Always specify Leading when specifying a Font, as the inherited or defaulted value may not be appropriate. 60.12.6 Technique - Controlling hyphenation. For each e-i-c, specify whether hyphenation should take place or not. If it should, the hyphenation characteristics specified in the document description apply. The only characteristic that can be overridden is the Hyphenation Zone. It may be desirable to disable hyphenation in text in large type, for example, chapter headings, or in table cells. 60.12.7 Technique - Specifying word spacing, letter spacing, and kerning. Word spacing, letter spacing, and kerning are generally set up for the document description and are rarely changed for a particular element. Typically, word and letter spacing values are specified with "em spaces". The actual size of an em space is determined by the font in use. This allows word and letter spacing to vary with the font in use. Specifying different values for Minimum, Nominal, and Maximum gives the formatter freedom to adjust letters and words during justification. Choose values that allow enough latitude yet render the text readable. 60.12.8 Technique - Using indents. Indents establish "margins" against which text can be positioned. Specify the indents relative to the column area boundaries, or specify indents relative to the text margins of the parent, for example, in the case of nested paragraphs. One typical use of indents is for "hanging" indents for lists and steps, where the first line contains a number, for example, to be "outdented" and the rest of the text appears as a block. To achieve this effect, specify the left margin for the block of text as a Left Indent (leftind) value on the e-i-c. Specify the left margin for the number as a subcharacteristic (subchar) to the Usetext used for outputting the number. 60.12.9 Technique - Specifying quadding. The Quadding values of "left", "right", "center", and "justify" represent typical typographic positioning techniques. The values "in" and "out" work exactly the same as "left" and "right" but leave the actual determination of which side to the formatter based on the bind edge. "In" and "out" are most commonly used in headers and footers. "Asis" instructs the formatter to try to put the same characters found on lines in the source (including spaces) on the same lines in the output. Typically, this is used when including computer program listings, example terminal screens, pseudo-graphics drawn with characters, and the like. As the original data is usually produced with a monospace device, it is best to specify a monospace font in conjunction with "asis" quadding. 60.12.10 Technique - Using highlighting. Scoring, Score Weight (scorewt), and Score Offset (scoreoff) are used for underlining, overbars, and strike-throughs. Additionally, a Score Character (scorechr) can be overlaid to achieve a "crossed out" effect, for example, with an "x". Reverse, Color, and Screens are used for special effects. 60.12.11 Technique - Specifying change marks. Specify that either a bar or literal string appears in the Change Mark Area to denote changed text. Specify a bar by indicating a Bar Thickness. Specify a literal by providing the string to appear, for example "rev1". Font and Highlight characteristics can be specified for the string; the leading is determined by the leading of the text the change mark corresponds to. 60.12.12 Technique - Specifying prespace and postspace. Prespace and Postspace specify the space before and after an element, respectively, and as such will abut each other. Some planning for prespace and postspace values will ensure that the FOSI reflects the formatting requirements. In general, first specify pre- and postspace where formatting requirements absolutely require it and place an Adjacency Priority of "force" with them. Then, analyze the general requirements for spacing between elements and try to specify the space as either prespace or postspace. In this way, conflicts will be avoided. When it is not possible to specify all of the spacing as either prespace or postspace, use priorities that will allow the formatter to make intelligent choices about how to distribute the space. Specifying different values for Minimum, Nominal, and Maximum gives the formatter freedom to adjust pre- and postspace during vertical justification. Choose values that allow enough latitude yet keep within the bounds of your formatting specification. 60.12.13 Technique - Specifying keeps. Keeps should be used with discretion because it is very easy to specify unrealistic expectations for the formatter. For example, turning on Keep for a chapter indicates to keep the entire chapter on a single page. As the content of the document is unknown, such a requirement may be impossible to fulfill. Turn on Keep for elements that fit on a single page. Note that tables and footnotes have special characteristics for controlling breaking across pages and graphics are inherently kept on a single page. A more common formatting requirement is to keep some pieces of adjoining elements together on a page, for example, to keep a title with the first two lines of the following paragraph. This type of requirement can be specified with Keep Next, Keep Previous, Widow Count, and Orphan Count. Set the Scope to indicate whether an element may break across columns or pages. 60.12.14 Technique - Specifying vertical justification parameters. In general, a formatter should attempt to honor all specifications for an element's Prespace, Postspace, and Keeps. However, in performing vertical justification, the formatter may need to make some adjustments in order to balance the text in the columns. Indicate for each e-i-c which values are most important by setting a Vertical Justification Priority on each. If such individual attention is not necessary, then set these priorities for the document description and they will become the default for all e-i-c's. 60.12.15 Technique - Specifying text breaks. Typically a formatting specification explicitly states requirements for starting text on new columns or pages, such as, starting chapters on a new page. This can be specified with Start Column and Start Page. In addition, the Page Model to be used when starting on a new page, for example, foldout pages can be specified. The OS makes no assumptions about whether elements start on a new line or not. This information must be explicitly specified for each element that starts on a new line. If most elements start on a new line, then turn on Start Line as the document default and explicitly turn it off for those elements that do not start on a new line. Turning on End Line is useful for situations where it cannot be predicted what element will follow, but it is known that it must begin on a new line. For example, the paragraph following the title in a primary paragraph is usually run-in, that is, it does not start on a new line. However, if a warning intercedes between the title and the paragraph, the paragraph must start on a new line (or else it would be run-in with the warning). The way to specify this is to turn on End Line for the warning. 60.12.16 Technique - Using spans. Span is used to specify that text normally placed within a single column in the Flowing Text Area should span all the columns. Note that tables, footnotes, and graphics have special characteristics for specifying their width. 60.12.17 Technique - Using borders. Borders that always appear on a particular type of page should be specified in the page specification (pagespec). In addition, the occurrence of certain elements on a page may trigger the appearance of a border, for example, emergency information. Border patterns are specified with a name, which is described in the declaration subset of the FOSI. 60.12.18 Technique - Using rules. Rules are used for "inline" rules within paragraph text, for example, a signature line, and to "outline" blocks of text, for example, around a heading. Multiple rules can be specified on a single e-i-c; each specification draws one rule. 60.12.19 Technique - Using character fills. The most common use of Character Fill is for leader dots. Character Fill patterns are specified in the resource description to set up how the fill string looks and to assign the string a unique name. To specify where the string appears in the output, use the unique name in the Source of a Usetext specification. 60.12.20 Technique - Using automatic numbering. Automatic numbering is typically specified for structural elements such as chapters, sections, paragraphs, and steps, as well as tables, figures, and footnotes. In a FOSI, set up "counters" that can be referenced by an e-i-c such that the actual value is maintained by the formatter. The Counter element in the resource description is used to set up each counter. Specify the style of the number when it is printed. Choose a numbering sequence, such as Arabic, or set up a specific ordered sequence. An example of a specific ordered sequence is daggers, double daggers, and so forth, for footnotes. Counters are assigned a unique identifier that can be referenced so that compound numbers can be created, for example, the paragraph number might include the chapter number. Specify how these counters are incremented and reset using the Enumeration category of an e-i-c. The Enumeration characteristics only set up how the counter is to be handled when the e-i-c it is associated with is encountered. To specify where the number appears in the output, the unique identifier must be included in the Source of a Usetext specification. Alternatively, the counter may have already been specified as part of the data in the Construction Rule of a Savetext specification and use of the Savetext identifier as the Source of the Usetext then includes the counter. 60.12.21 Technique - Suppressing text. Occasionally, text is marked up in the source document that is intended to be used for some purpose other than in the normal text flow. For example, a short title is provided for use in the Table of Contents or running header but does not appear as part of the title. In this case, it is necessary to indicate that the content of the short title does not appear in the normal text flow by turning on the Suppress characteristic. The entire content of the title, including any marked-up elements within it (such as emphasis), should not appear in the normal text flow. Typically, the text is saved with a Savetext so that it can be used elsewhere. 60.12.22 Technique - Using generated text (Puttext). Often, the formatting specification requires the generation of a standard piece of text with each occurrence of an element, for example, the "Note" heading for a note. This text does not appear in the source document itself, however, by specifying it in the FOSI, it can be ensured that it is consistent throughout the document. Puttext allows for specifying a text string that is to appear before or after the element's content. Subcharacteristics can be used to describe the style and positioning of the text string. 60.12.23 Technique - Using pre-defined graphics (Putgraph). There are cases where graphics appear in the document that are not part of figures, such as the ESDS symbol. Putgraph allows identification of these graphics and specify how they appear in running text. In addition, Putgraph can be used for some specific generated "text" instead of usetext, for example, warning heads in 3-D boxes. These graphics are to be treated as a single "character" for positioning by the formatter. Specifying the width and depth of the graphic, as the formatter does not have font metric information available to use to position the graphic, is a requirement. 60.12.24 Technique - Saving text for multiple uses (Savetext). Savetext allows for "saving" the content of an element for use elsewhere in the document, for example in the header, footer, or Table of Contents. The content still appears in the Flowing Text Area in its normal sequence (unless inhibited by use of the Suppress category). Savetext can be used to save combinations of other saved text, saved counters, pseudo-elements, and literals. Usetext is used to "retrieve" the saved text and specify how it is used. Ordinarily, when a subsequent Savetext is done with the same Savetext text id as a previous Savetext, the subsequent one replaces the previous one. This is the behavior when the Append characteristic has the value "off" (its default). However, if the value of the Append characteristic is "on", the value in the conrule of the savetext would be "appended" to the text already saved to this Savetext text id. Consecutive Savetexts with the same Savetext Name and Append="on" would cause all the saved text to accumulate, and a subsequent Usetext would "retrieve" the entire accumulated set. Note that tags may be caused to be saved either by being subelements of the current element whose content is saved by a reference to #CONTENT or by an explicit reference to a pseudo-element in the Savetext Construction Rule. These tags (whether elements or pseudo-elements) will have formatting characteristics associated with them via an e-i-c entry in the FOSI. This makes it possible to save text, each formatted differently, and reformat the text at the time of use. In addition to saving the entire content of the element, only a portion of the element may be saved by using the start position, end position, delimiter, and occurrence characteristics. For example, an element may contain a date separated by "/" characters, such as "01/02/90". It may be useful to extract this date into its component parts. One way to do this would be using the start position and end position characteristics. The month could be extracted by saving positions 1 through 2, the day by saving positions 4 through five and the year by saving positions 7 through 8. Another method would be to use the delimiter and occurrence characteristics. Using this method, the month could be extracted by saving the text up to the first delimiter (the "/"), the day could be extracted by saving the text between the first and second delimiters, and the year could be extracted by saving the text after the second delimiter. 60.12.25 Technique - Using saved text (Usetext). Usetext specifies how any text saved via Savetext is used. Subcharacteristics can be used to specify the style and positioning of the retrieved text. The Usage Rule specifies any additional information needed to process the text (see 30.1.4.11). 60.12.26 Technique - Interaction of Puttext, Putgraph, Ruling, and Usetext. When more than one Puttext, Putgraph, Ruling, and/or Usetext is specified on an e-i-c, the order of their occurrence in the FOSI is significant. That is, the text or graphics should appear in the same order in the output as they specified in the FOSI, followed by the context of the element followed by all text or graphics specified with placement of after. 60.12.27 Technique - Using string. All variables which are time independent (i.e. have the same value regardless of when they are used), must be specified with their time status attribute set to "1". The scope attribute can be used to indicate which element specified by the Scope characteristic must be an ancestor of the e-i-c instance in which this instance occurs; if not, the variable will be resolved at the end of the document element. An example would be the string which contains the collective information to produce a table of contents would be specified as time independent with its time end attribute set to doc. 60.13 Step 12 - Handling source attributes. 60.13.1 Technique - Identifying source attributes. Source attributes that affect formatting must be identified in the FOSI with each e-i-c for which that attribute can be specified. An attribute is identified through Attname. The value should be the name of the attribute, exactly as it appears in the source DTD. In addition, it is possible to refer to attributes that were specified for ancestors of the e-i-c through Attloc. The value of Attloc should be the name of an ancestor of the e-i-c and is assumed to be the most immediate ancestor of that element type. For example, when specifying the characteristics for a section title (gi = "title", context = "section"), it may be necessary to know whether the "tocentry" attribute was set on the section in order to determine whether to save the contents of the title for use in the Table of Contents. To specify this in the "att" section of the FOSI entry for the title, specify a value of "tocentry" for Attname and "section" for Attloc. When no value is supplied for Attloc, the attribute is assumed to have been specified for the e-i-c being described. When the value #FOSI is supplied for attloc, the attribute indicated in attname is an internal FOSI variable. 60.13.2 Technique - Specifying the use of the attribute. There are two ways of specifying how an attribute value is to be used: Specval and Fillval. For Specval, one possible value of the attribute is identified through Attval. When that value actually appears in the source document for the e-i-c, the characteristics specified in the Characteristic subset for the Specval take affect. The string "#NONZERO" can be used to indicate any non-zero value, the string "#NONE" may be supplied for attributes whose declared value is #IMPLIED to indicate that no assignment was made to that attribute in the source document, and the string "#ANY" indicates any value. Furthermore, for attributes whose declared value is a number, an "attval" string may be of the form "#xx#yyy" where 'xx' is one of the letter pairs LT, GT, EQ, LE, GE, NE and 'yyy' is a numeric constant. This allows some simple arithmetic conditions to be tested using Specval. In addition, the prefix "#ITEM#" is used to indicate that the value is one out of a list. There will then be multiple Specvals with the same Attname, with each possible value in the list as an Attval. The characteristics specified for these list items are cumulative. That is, for all the values that actually occur in the list, all the corresponding characteristics take effect. For example, the declared value for the "emph" attribute on the "emphasis" element is NAMES (a list of names). For each possible value, for example, "bold", "italic", and "underline", provide a Specval with a list of characteristics for each. Then, when the actual attribute value is "bold underline", the characteristics specified for "bold" and "underline" take effect. For Fillval, the value of the attribute is actually used as the value for a characteristic identified by its category (Fillcat) and characteristic name (Fillchar). The Fillcat and Fillchar values must be names of elements defined in the OS DTD. Use the Characteristic subset to specify the values of the other characteristics of the category used in the Fillcat. Fillval is useful when the value for a characteristic is determined by the author of the source document as opposed to the author of the FOSI, for example, the number of columns in a table. If the declared value of the attribute is CDATA, the comparison will be case sensitive otherwise it will not be case sensitive. 60.13.3 Technique - Interaction of attributes and other values. In general, set up the characteristics for an element without regard to the possible attributes that may affect it. Then, in the attribute specification (att), override the "typical" values through the characteristics specified in the characteristic lists (charlist) specified for the attributes. In some cases, the value of an attribute is so integral to the nature of the element that it may not be possible to set up "typical" characteristics without considering the attribute values. In this case, there is no need to set up characteristics outside of the attribute specification. For a further discussion of attribute specifications, refer to 30.3.3. 60.14 Step 13 - Describing graphics. 60.14.1 Overview of graphics functionality. The graphics functionality has been designed to ensure that a formatting system is able to reproduce an illustration according to the specifications of the author/illustrator in such a way that it fits in with the design specifications of a FOSI. In particular it allows for: 1. The author to pass relevant sizing, cropping and placement information. 2. The author to specify exactly which portion of graphic board is to be used for the illustration, such that a "window" view of a graphic can be used. 3. The author to easily specify a particular set of values to be used by supplying a "Graphic Style" name. 60.14.2 Methodology. While the actual graphics used in an illustration are typically unique, it is often the case that functional specifications allow for a small set of different size illustrations. For example, only page width or column width illustrations may be allowed and may have specific width dimensions specified for each. There may also be a requirement that a particular set of graphics be placed in a document in a uniform way, for example, with 1/4 inch white space surrounding each graphic. Both to accommodate these possible requirements and to ease the job of the author, it is possible to specify different sets of graphic characteristic values and provide a name for each set of these "Graphic Styles". In every FOSI there is one required Graphic Style which has the name "default". This default set of characteristic values allows the author to leave out attribute values that are supplied in the FOSI, and also allows for additional Graphic Styles to be specified easily in a FOSI. The first step in determining useful values for the graphic characteristics in a FOSI is to review the functional requirements. Are there different types of graphic reproduction areas (the area on the media or page within which the graphic may be placed)? Are they compatible with the Page Models specified in the FOSI? If all graphics used will be the width of a page, then it is obvious that the reproduction area dimensions for the default Graphic Style should be based on the width of a page. If there are two types of graphics, one page width and one column width, then which is more common should have its values specified in the default Graphic Style and a second Graphic Style should provide the other values. As is always the case where an author can specify attribute values that affect formatting, the author's values override the FOSI characteristics. This allows for authors to make an exception where necessary, but also frees them from having to specify many attributes when they are already provided in the FOSI. 60.15 Step 14 - Describing tables. In the Table Description of a FOSI, identify all elements in the source DTD relating to tables and map them to their corresponding object in the table output structure. In addition, specify the composition characteristics for the content of the table. Following is one approach for describing tables. a. Set up the Table characteristics (tabatts) for each basic kind of table, for example, in-line and floating, ruled and unruled, and different page breaking requirements. Set up the Standard Cell Attributes (stdcellatts) here as the "default" settings for the whole table. b. Put each tabatts in a tabstyle and assign the tabstyleid a unique name that indicates what kind of table it is, for example, "floatruled". Provide the table e-i-c from the source for each tabstyle. It is possible to use the same e-i-c for more than one tabstyle, for example "table"; the unique tabstyleid distinguishes tabstyles. c. In the e-i-c of the tabstyle, specify how the table is positioned within the flowing text using Quadding, Indents, Prespace, Postspace, Keeps, and Textbrk. Note that Span does not override the width specified for the table. Other characteristics for generating data, such as rules, borders, text, and graphics may also be used to put additional data in the flowing text. Style characteristics for text, such as Font, Leading, Hyphen, Wordsp, Lettersp, and Highlt have no immediate effect on the table but can be set up so that they can be inherited by another e-i-c. d. Next, set up a subsetstyle for each unique type of table subset. Again, provide a unique name for the subsetstyleid to distinguish it from others. In general, for every characteristic that can be overridden by an attribute in the source, provide a Fillval construct, as well as provide values in the FOSI for cases where the values are not provided in the source. Stdcellatts can be specified for any object in the table subset and apply to the cells within that object. e. For the e-i-cs supplied in the subsetspec, colspec, rowspec, and cellspec, Composition Characteristics (a charlist) can be supplied and apply to the text within the cells that are in the scope of the object. f. In the subsetatts, the number of columns for the table is specified. In the DTD in appendix A, the number of columns in the table is a required attribute, so a Fillval construct is sufficient. Provide the table group e-i-c from the source for each subsetspec. Again, use the same e-i-c for more than one subsetspec, for example "tgroup"; the unique subsetstyleid distinguishes them. g. Set up a colspec for the columns in the table. Typically, as in the case of the DTD in appendix A, all colatts are supplied from the source, so they should all have a Fillval construct. In cases where columns are uniquely identified in the source structure by different elements, it may be necessary to set up a colspec for each. Provide the column e-i-c from the source for each colspec. h. Set up a rowspec for the rows in the table. Again, one rowspec is sufficient unless there are unique row elements in the source table structure. Provide the row e-i-c from the source for each rowspec. i. Set up a cellspec for the cells in the table. Typically, cellatts are supplied from the source, so they should all have a Fillval construct. Provide the cell e-i-c from the source for each cellspec. j. Consider all elements that can occur in a table as content, as it is likely that they are formatted differently than in normal flowing text. Include an e-i-c for each of these elements in the Table Description with the Composition Characteristics that apply within the table. 60.16 Step 15 - Describing footnotes. There are several aspects to describing footnotes. The Footnote Area element, subordinate to the Flowing Text Area in the Page Description section of the FOSI, has various attributes that describe characteristics of the footnote area such as footnote placement and separators. This Footnote Area element has subcharacteristics to specify further the formatting of the various footnote separators. Note that the subcharacteristics in the Footnote Area are not used to affect the formatting of the text of the footnotes themselves. In the footnote description (ftndesc) section of the FOSI, one gives the e-i-cs that describe the elements (or pseudo-elements) that will cause their contents to be placed in the footnote area of the page on which these elements are used. Associated with each e-i-c in the ftndesc is a ftnatts which contains a charlist (minus keeps and span) that specifies the formatting of the footnote content itself. More precisely, the contents (e.g., the charlist) of the e-i-c in the ftndesc determines the characteristics for what gets placed in the flowing text area when this e-i-c instance is encountered; the contents (i.e., the charlist) of the ftnatts associated with this e-i-c determines the characteristics for what gets placed in the footnote area when this e-i-c is encountered. The contents of this e-i-c (the source document element's content) is placed into the footnote area under control of the characteristics defined by the ftnatts (unless the ftnatts' charlist uses the Suppress characteristic). (The ftnatt's charlist may specify a default environment [envname]; however, the use of inheritance in the ftnatt's charlist or any of its categories will be ignored.) In the simpler case where the source DTD has defined an element whose content is the footnote text and whose location in the document instance determines where the footnote callout is to be placed, this element would be described in the ftndesc and no other element is required. Assuming such a DTD element called ftnote, the ftndesc might look like: <ftndesc> <e-i-c gi="ftnote"> <!-- typeset callout in flowtext --> <charlist inherit="1"> <!-- we assume ftnctr has an appropriate 'counter' entry in the rsrcdesc --> <enumerat increm="1" enumid="ftnctr"> <usetext source="ftnctr"> <subchars> <font inherit="1" size="6pt" offset="-4pt"> </subchars> </e-i-c> <ftnatts> <!-- typeset superscript and footnote text in footnote area --> <charlist> <font size="8pt"> <leading lead="9pt"> <!-- we assume the default (docdesc) indent and quadding is appropriate for the footnotes --> <presp minimum="2pt" nominal="3pt" maximum="4pt"> <textbrk startln="1"> <usetext source="ftnctr" placemnt="before"> <subchars> <font size="5pt" offset="-3pt"> </subchars> </ftnatts> </ftndesc> A source document fragment such as: <para>This is a paragraph<ftnt>This is a footnote.</ftnt> with a footnote in it.</para> would cause a superscript number to be placed after the word "paragraph" in the paragraph and a footnote with an initial superscript number and the text "This is a footnote." to be placed in the footnote area of the current page. In the more complex situation used in the template DTD in appendix A, there is one element (ftnote) whose content is the footnote text but whose position in the document instance is irrelevant and another element (ftnref) with no content but whose position determines (1) the location of the callout in the flowing text and (2) the page in whose footnote area the footnote text will be placed. The ftnref element has an IDREF attribute that refers to the ftnote element's ID attribute to allow the ftnref to reference the appropriate footnote text. To accomplish this, the ftnote e-i-c must use the Savetext category to save its contents for later use by the ftnref e-i-c. Neither the ftnote e-i-c nor the ftnref e-i-c are "special" in that they both appear in the styldesc part of the FOSI. The ftnref element must (1) cause the footnote callout number to appear in the flowing text and (2) cause the previously saved footnote text to be placed in the footnote area of the current page. Both effects are accomplished by using (via Usetext) the saved footnote text surrounded by the tags of the element (in this case, a pseudo-element) defined in the ftndesc. Note that this case could use the same ftndesc as described above. Furthermore, there would be e-i-c entries in the styldesc for ftnote and ftnref as follows: <e-i-c gi="ftnote"> <!-- don't typeset anything, but save this element's contents as the contents of a <ftnt>...</ftnt> element --> <charlist> <suppress sup="1"> </charlist> <att> <fillval attname="id" fillcat="savetext" fillchar="textid"> </att> </e-i-c> <e-i-c gi="ftnref"> <!-- reference (via usetext) the previously saved footnote text --> <charlist> </charlist> <att> <fillval attname="xrefid" fillcat="usetext" fillchar="source"> </att> </e-i-c> A source document fragment such as: <ftnote id="xyz">This is a footnote.</ftnote> . . . <para>This is a paragraph<ftnref xrefid="xyz"> with a footnote in it.</para> would cause the same output as in the previous case. 60.17 Step 16 - Verifying the FOSI. When the FOSI is completed for the entire document, verify that the encoding conforms to the OS DTD by running an SGML parser. The parser confirms that the SGML syntax is correct and, in the case where characteristic values are a Finite List, verifies that correct values have been specified. The SGML parser cannot verify that other values make sense. It is the FOSI author's responsibility to ensure that the FOSI accurately reflects the formatting specification and that all required values have been specified. 70. GLOSSARY 70.1 Equivalency definitions. The following values should be used for conversion purposes: 1 inch = 72 points +/- 0.4 percent 1 pica = 12 points 70.2 Definition of terms. 70.2.1 Attribute name. The name of an attribute as assigned in the attribute definition list declaration of a DTD. 70.2.2 Border. Graphic that appears along page boundaries. 70.2.3 Character fill. The repeated use of a character, or string of characters, to occupy space within running text, for example, leader dots. 70.2.4 Characteristic. Specification of a formatting property for a logical element. The characteristics of text, graphics, and tables define how they are processed and output by the system. 70.2.5 Context. The lineage of parent elements of a particular element type in a DTD, and its representation in a FOSI. Context is a part of element-in-context specification. 70.2.6 Coordinate, world system. System used to describe the two-dimensional space in which a graphic is defined. The world coordinate system is comprised of X and Y coordinates having a point of origin in the lower left corner (coordinates 0, 0) and the upper right corner (coordinates 10000, 10000). 70.2.7 Default. Characteristic values that are assigned to the document element or a named environment from which characteristic values can be derived if left unspecified and not inherited. 70.2.8 Document Type Definition (DTD). Rules that are required to apply the Standard Generalized Markup Language (SGML) to document markup. The DTD includes a formal specification of the document element types, their relationships and attributes, and references that can be represented by markup. It therefore defines the vocabulary of the markup for which SGML defines the syntax. It is determined by the document's application. Specifically, the document type definition specifies: a. The generic identifies (GIs) of elements that are permissible in a document of this type. b. For each GI, the possible attributes, their range of values, and defaults. c. For each GI, the structure of its content, including: 1. which subelement GIs can occur and in what order; 2. whether text characters can occur; 3. whether noncharacter data can occur. 70.2.9 Element-in-context (e-i-c). The complete set of information necessary to identify a particular set of instances of an element type within a document, including its generic identifier, context, and occurrence. 70.2.10 e-i-c. See element-in-context. 70.2.11 Em space is the horizontal space taken up by a capital 'M'. It is the same width as the current point size. The size in em spaces is determined by the font in use. 70.2.12 Enumeration. The ordering of like elements by the composition system. The numbers that are to be generated by the system are identified as counters and may be combined with other counters and literals to form compound numbers. 70.2.13 Font. Collection of character images. A font is a complete set of characters in one design and size. A font system creates character sets that are derivative of character representations. Expanded, italic, and bold fonts are three different fonts and the medium font, that the derivatives are based on, is a different font. 70.2.14 Formatting Output Specification Instance (FOSI). The set of characteristics and values chosen from the Output Specification to represent the formatting requirements for a particular type of document. A FOSI is an SGML document conforming to the OS DTD. 70.2.15 Generic identifier (GI). Unique name that identifies and refers to an element type in a DTD. The generic identifier (GI) is part an element-in-context. 70.2.16 GI. See generic identifier. 70.2.17 Graphic placement. Horizontal and vertical placement of a graphic within a reproduction area. Graphic placement can be specified with relative values or coordinates. 70.2.18 Graphic sizing. Constraints on the size or view of graphics to be placed in reproduction area dimensions. Graphics can be scaled and cropped. 70.2.19 Highlight. Special presentation characteristics for text, including scoring, color, and screens. 70.2.20 Hyphenation. Breaking a word at the end of a line of text for purposes of line justification. 70.2.21 Identifier (ID). An identifier that is unique throughout a document. 70.2.22 Identifier reference (IDREF). A reference to an ID. 70.2.23 Indent. Positioning in the writing (horizontal) direction. Indents can be relative to area boundaries or margins set by other indents. 70.2.24 Inheritance. Mechanism whereby unspecified characteristic values are derived from the corresponding values assigned to the parent element. 70.2.25 Justification, vertical. The positioning of text lines in the vertical direction for purposes of column balancing. 70.2.26 Keeps. Conditions for controlling or disallowing breaking elements over column or page boundaries. 70.2.27 Layout areas. Rectangular areas on a page in which element content is placed. 70.2.28 Leading. The amount of space between the baseline of text lines in a single element. 70.2.29 Letterspace. Space between letters in a word that may be adjusted for purposes of line justification. 70.2.30 List, finite. The set of choices for the value of a particular characteristic. 70.2.31 Margin, bind. Area of a page designated for binding, that is, physically connecting pages with a staple, stitch, or glue. Typically, the bind margin of a page is larger than the opposite margin to allow for the space taken up by binding. The bind margin also serves as a reference for quadding of text that is toward the inside of the book (in) or toward the outside of the book (out). 70.2.32 Occurrence. Order of appearance of an element in relation to other like elements. 70.2.33 Output Specification (OS). Guidelines for the interchange of style and formatting information of technical manuals between all types of publishing systems. The OS provides the range of possible ways of describing formatting requirements. 70.2.34 Page Fidelity. Preservation of the exact presentation characteristics and the exact information on pages exchanged between systems. 70.2.35 Page integrity. Preservation of the exact information on each page as it is exchanged between systems. Page integrity does not guarantee that information will be presented on the page in exactly the same way after exchange between systems (page fidelity). 70.2.36 Page model. Collection of pagination characteristics describing the layout areas that occur on a page. 70.2.37 Page set. A page model that is used for a set of like pages that vary only when they are recto, verso, or blank. 70.2.38 Parseability, machine. The ability to verify, through a computer program, that a FOSI has correct syntax (conforms to the OS DTD). 70.2.39 Point. Unit of measurement equal to 1/72 inch. 70.2.40 Pointer. A reference to information contained in an external file. Pointers behave like SGML external entity references. 70.2.41 Postspace. Amount of space in the vertical direction added after content (in addition to its leading). 70.2.42 Prespace. Amount of space in the vertical direction added before content (in addition to its leading). 70.2.43 Priority. Specification of which values take precedence when there is a conflict. The priority characteristic range of values is "Force", "High", "Medium", "Low", and "None". Force has the greatest priority value and none has the least. The value is compared to provide a solution to the conflict. Where priority characteristic values are equal, there are additional precedence rules that are applied depending on where the characteristic is encountered. 70.2.44 Puttext. Describes system-generated text that appears in the output data stream. 70.2.45 Pseudo-element. A construct that can act as a reference to an e-i-c entry in the FOSI. 70.2.46 Quadding, horizontal. Horizontal alignment of text lines within an element with respect to the layout area boundaries. 70.2.47 Quadding, vertical. Vertical alignment of an element with respect to area boundaries. 70.2.48 Reproduction area dimensions. The width and depth of an area that is to be filled with a graphic. 70.2.49 Ruling. Drawing of a line segment. 70.2.50 Savetext. Text to be saved for use elsewhere in a document. 70.2.51 Span. Positioning of content across all columns on a page. 70.2.52 String. Literal sequence of characters, including alpha, numeric, and special (pi) characters. 70.2.53 Textbreak. Characteristics for controlled interruptions of normal text flow, including starting text at the beginning of a column, page, or line. 70.2.54 Toggle. A value type treated as a Boolean variable where the only distinction between values is zero (off) and non-zero (on). 70.2.55 Usetext. Describes the use of content that has been saved with the Savetext characteristic. 70.2.56 Wildcard. Specification of zero or more levels of ancestry in a context that are not called out by name. 70.2.57 Wordspace. Space between words in a text line that may be adjusted for purposes of line justification. 70.3 Acronyms. a. CCITT Consultative Committee on International Telegraphy and Telephony. b. CGM Computer Graphics Metafile. c. DTD Document Type Definition. d. e-i-c Element-in-context. e. FOSI Formatting Output Specification Instance. f. GI Generic Identifier. g. IGES Initial Graphics Exchange Specification. h. ISO International Standards Organization. i. OS Output Specification. j. WYSIWYG What You See Is What You Get. LIBRARY OF AVAILABLE CHARACTER SET ENTITY DECLARATIONS LIBRARY OF AVAILABLE DATA CONTENT NOTATION DECLARATIONS LIBRARY OF AVAILABLE REPLACEMENT TEXT ENTITY DECLARATIONS LIBRARY OF AVAILABLE PUBLIC TABLE DEFINITIONS MATH DECLARATION SET ELECTRONIC REVIEW DECLARATION SET 10. INTRODUCTION 10.1 Scope. This appendix specifies the character set entity declarations, data content notation declarations, replacement text entity declarations, and declaration set for mathematical formulae available for use with any document type declaration in this specification or any document type declaration created in compliance with this specification. 20. APPLICABLE DOCUMENTS 20.1 Applicable documents. This section is not applicable to this appendix. 30. CHARACTER SET ENTITY DECLARATIONS 30.1 Character set entity declarations. The following lists the PUBLIC identifiers and the group of character set entity declarations associated with each PUBLIC identifier which are available for use in DoD publications conforming to this specification. To make the entity declarations within any set available within a document type declaration, the document type declaration must contain the PUBLIC entity declaration and the parameter entity reference to the declaration, as shown in the "typical invocation." <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOamsa PUBLIC "ISO 8879:1986//ENTITIES Added Math Symbols: Arrow Relations//EN"> %ISOamsa; --> <!ENTITY cularr SDATA "[cularr]"--/curvearrowleft A: left curved arrow --> <!ENTITY curarr SDATA "[curarr]"--/curvearrowright A: rt curved arrow --> <!ENTITY dArr SDATA "[dArr ]"--/Downarrow A: down dbl arrow --> <!ENTITY darr2 SDATA "[darr2 ]"--/downdownarrows A: two down arrows --> <!ENTITY dharl SDATA "[dharl ]"--/downleftharpoon A: dn harpoon-left --> <!ENTITY dharr SDATA "[dharr ]"--/downrightharpoon A: down harpoon-rt --> <!ENTITY lAarr SDATA "[lAarr ]"--/Lleftarrow A: left triple arrow --> <!ENTITY Larr SDATA "[Larr ]"--/twoheadleftarrow A:--> <!ENTITY larr2 SDATA "[larr2 ]"--/leftleftarrows A: two left arrows --> <!ENTITY larrhk SDATA "[larrhk]"--/hookleftarrow A: left arrow-hooked --> <!ENTITY larrlp SDATA "[larrlp]"--/looparrowleft A: left arrow-looped --> <!ENTITY larrtl SDATA "[larrtl]"--/leftarrowtail A: left arrow-tailed --> <!ENTITY lhard SDATA "[lhard ]"--/leftharpoondown A: l harpoon-down --> <!ENTITY lharu SDATA "[lharu ]"--/leftharpoonup A: left harpoon-up --> <!ENTITY hArr SDATA "[hArr ]"--/Leftrightarrow A: l&r dbl arrow --> <!ENTITY harr SDATA "[harr ]"--/leftrightarrow A: l&r arrow --> <!ENTITY lrarr2 SDATA "[lrarr2]"--/leftrightarrows A: l arr over r arr --> <!ENTITY rlarr2 SDATA "[rlarr2]"--/rightleftarrows A: r arr over l arr --> <!ENTITY harrw SDATA "[harrw ]"--/leftrightsquigarrow A: l&r arr-wavy --> <!ENTITY rlhar2 SDATA "[rlhar2]"--/rightleftharpoons A: r harp over l --> <!ENTITY lrhar2 SDATA "[lrhar2]"--/leftrightharpoons A: l harp over r --> <!ENTITY lsh SDATA "[lsh ]"--/Lsh A:--> <!ENTITY map SDATA "[map ]"--/mapsto A:--> <!ENTITY mumap SDATA "[mumap ]"--/multimap A:--> <!ENTITY nearr SDATA "[nearr ]"--/nearrow A: NE pointing arrow --> <!ENTITY nlArr SDATA "[nlArr ]"--/nLeftarrow A: not implied by --> <!ENTITY nlarr SDATA "[nlarr ]"--/nleftarrow A: not left arrow --> <!ENTITY nhArr SDATA "[nhArr ]"--/nLeftrightarrow A: not l&r dbl arr --> <!ENTITY nharr SDATA "[nharr ]"--/nleftrightarrow A: not l&r arrow --> <!ENTITY nrarr SDATA "[nrarr ]"--/nrightarrow A: not right arrow --> <!ENTITY nrArr SDATA "[nrArr ]"--/nRightarrow A: not implies --> <!ENTITY nwarr SDATA "[nwarr ]"--/nwarrow A: NW pointing arrow --> <!ENTITY olarr SDATA "[olarr ]"--/circlearrowleft A: l arr in circle --> <!ENTITY orarr SDATA "[orarr ]"--/circlearrowright A: r arr in circle --> <!ENTITY rAarr SDATA "[rAarr ]"--/Rrightarrow A: right triple arrow --> <!ENTITY Rarr SDATA "[Rarr ]"--/twoheadrightarrow A:--> <!ENTITY rarr2 SDATA "[rarr2 ]"--/rightrightarrows A: two rt arrows --> <!ENTITY rarrhk SDATA "[rarrhk]"--/hookrightarrow A: rt arrow-hooked --> <!ENTITY rarrlp SDATA "[rarrlp]"--/looparrowright A: rt arrow-looped --> <!ENTITY rarrtl SDATA "[rarrtl]"--/rightarrowtail A: rt arrow-tailed --> <!ENTITY rarrw SDATA "[rarrw ]"--/squigarrowright A: rt arrow-wavy --> <!ENTITY rhard SDATA "[rhard ]"--/rightharpoondown A: rt harpoon-down --> <!ENTITY rharu SDATA "[rharu ]"--/rightharpoonup A: rt harpoon-up --> <!ENTITY rsh SDATA "[rsh ]"--/Rsh A:--> <!ENTITY drarr SDATA "[drarr ]"--/searrow A: downward rt arrow --> <!ENTITY dlarr SDATA "[dlarr ]"--/swarrow A: downward l arrow --> <!ENTITY uArr SDATA "[uArr ]"--/Uparrow A: up dbl arrow --> <!ENTITY uarr2 SDATA "[uarr2 ]"--/upuparrows A: two up arrows --> <!ENTITY vArr SDATA "[vArr ]"--/Updownarrow A: up&down dbl arrow --> <!ENTITY varr SDATA "[varr ]"--/updownarrow A: up&down arrow --> <!ENTITY uharl SDATA "[uharl ]"--/upleftharpoon A: up harpoon-left --> <!ENTITY uharr SDATA "[uharr ]"--/uprightharpoon A: up harp-r--> <!ENTITY xlArr SDATA "[xlArr ]"--/Longleftarrow A: long l dbl arrow --> <!ENTITY xhArr SDATA "[xhArr ]"--/Longleftrightarrow A: long l&r dbl arr--> <!ENTITY xharr SDATA "[xharr ]"--/longleftrightarrow A: long l&r arr --> <!ENTITY xrArr SDATA "[xrArr ]"--/Longrightarrow A: long rt dbl arr --> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOamsb PUBLIC "ISO 8879:1986//ENTITIES Added Math Symbols: Binary Operators//EN"> %ISOamsb; --> <!ENTITY amalg SDATA "[amalg ]"--/amalg B: amalgamation or coproduct--> <!ENTITY Barwed SDATA "[Barwed]"--/doublebarwedge B: log and, dbl bar--> <!ENTITY barwed SDATA "[barwed]"--/barwedge B: logical and, bar above--> <!ENTITY Cap SDATA "[Cap ]"--/Cap /doublecap B: dbl intersection--> <!ENTITY Cup SDATA "[Cup ]"--/Cup /doublecup B: dbl union--> <!ENTITY cuvee SDATA "[cuvee ]"--/curlyvee B: curly logical or--> <!ENTITY cuwed SDATA "[cuwed ]"--/curlywedge B: curly logical and--> <!ENTITY diam SDATA "[diam ]"--/diamond B: open diamond--> <!ENTITY divonx SDATA "[divonx]"--/divideontimes B: division on times--> <!ENTITY intcal SDATA "[intcal]"--/intercal B: intercal--> <!ENTITY lthree SDATA "[lthree]"--/leftthreetimes B:--> <!ENTITY ltimes SDATA "[ltimes]"--/ltimes B: times sign, left closed--> <!ENTITY minusb SDATA "[minusb]"--/boxminus B: minus sign in box--> <!ENTITY oast SDATA "[oast ]"--/circledast B: asterisk in circle--> <!ENTITY ocir SDATA "[ocir ]"--/circledcirc B: open dot in circle--> <!ENTITY odash SDATA "[odash ]"--/circleddash B: hyphen in circle--> <!ENTITY odot SDATA "[odot ]"--/odot B: middle dot in circle--> <!ENTITY ominus SDATA "[ominus]"--/ominus B: minus sign in circle--> <!ENTITY oplus SDATA "[oplus ]"--/oplus B: plus sign in circle--> <!ENTITY osol SDATA "[osol ]"--/oslash B: solidus in circle--> <!ENTITY otimes SDATA "[otimes]"--/otimes B: multiply sign in circle--> <!ENTITY plusb SDATA "[plusb ]"--/boxplus B: plus sign in box--> <!ENTITY plusdo SDATA "[plusdo]"--/dotplus B: plus sign, dot above--> <!ENTITY rthree SDATA "[rthree]"--/rightthreetimes B:--> <!ENTITY rtimes SDATA "[rtimes]"--/rtimes B: times sign, right closed--> <!ENTITY sdot SDATA "[sdot ]"--/cdot B: small middle dot--> <!ENTITY sdotb SDATA "[sdotb ]"--/dotsquare /boxdot B: small dot in box--> <!ENTITY setmn SDATA "[setmn ]"--/setminus B: reverse solidus--> <!ENTITY sqcap SDATA "[sqcap ]"--/sqcap B: square intersection--> <!ENTITY sqcup SDATA "[sqcup ]"--/sqcup B: square union--> <!ENTITY ssetmn SDATA "[ssetmn]"--/smallsetminus B: sm reverse solidus--> <!ENTITY sstarf SDATA "[sstarf]"--/star B: small star, filled--> <!ENTITY timesb SDATA "[timesb]"--/boxtimes B: multiply sign in box--> <!ENTITY top SDATA "[top ]"--/top B: inverted perpendicular--> <!ENTITY uplus SDATA "[uplus ]"--/uplus B: plus sign in union--> <!ENTITY wreath SDATA "[wreath]"--/wr B: wreath product--> <!ENTITY xcirc SDATA "[xcirc ]"--/bigcirc B: large circle--> <!ENTITY xdtri SDATA "[xdtri ]"--/bigtriangledown B: big dn tri, open--> <!ENTITY xutri SDATA "[xutri ]"--/bigtriangleup B: big up tri, open--> <!ENTITY coprod SDATA "[coprod]"--/coprod L: coproduct operator--> <!ENTITY prod SDATA "[prod ]"--/prod L: product operator--> <!ENTITY sum SDATA "[sum ]"--/sum L: summation operator--> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOamsc PUBLIC "ISO 8879:1986//ENTITIES Added Math Symbols: Delimiters//EN"> %ISOamsc; --> <!ENTITY rceil SDATA "[rceil ]"--/rceil C: right ceiling--> <!ENTITY rfloor SDATA "[rfloor]"--/rfloor C: right floor--> <!ENTITY rpargt SDATA "[rpargt]"--/rightparengtr C: right paren, gt--> <!ENTITY urcorn SDATA "[urcorn]"--/urcorner C: upper right corner--> <!ENTITY drcorn SDATA "[drcorn]"--/lrcorner C: downward right corner--> <!ENTITY lceil SDATA "[lceil ]"--/lceil O: left ceiling--> <!ENTITY lfloor SDATA "[lfloor]"--/lfloor O: left floor--> <!ENTITY lpargt SDATA "[lpargt]"--/leftparengtr O: left parenthesis, gt--> <!ENTITY ulcorn SDATA "[ulcorn]"--/ulcorner O: upper left corner--> <!ENTITY dlcorn SDATA "[dlcorn]"--/llcorner O: downward left corner--> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOamsn PUBLIC "ISO 8879:1986//ENTITIES Added Math Symbols: Negated Relations//EN"> %ISOamsn; --> <!ENTITY gnap SDATA "[gnap ]"--/gnapprox N: greater, not approximate--> <!ENTITY gne SDATA "[gne ]"--/gneq N: greater, not equals--> <!ENTITY gnE SDATA "[gnE ]"--/gneqq N: greater, not dbl equals--> <!ENTITY gnsim SDATA "[gnsim ]"--/gnsim N: greater, not similar--> <!ENTITY gvnE SDATA "[gvnE ]"--/gvertneqq N: gt, vert, not dbl eq--> <!ENTITY lnap SDATA "[lnap ]"--/lnapprox N: less, not approximate--> <!ENTITY lnE SDATA "[lnE ]"--/lneqq N: less, not double equals--> <!ENTITY lne SDATA "[lne ]"--/lneq N: less, not equals--> <!ENTITY lnsim SDATA "[lnsim ]"--/lnsim N: less, not similar--> <!ENTITY lvnE SDATA "[lvnE ]"--/lvertneqq N: less, vert, not dbl eq--> <!ENTITY nap SDATA "[nap ]"--/napprox N: not approximate--> <!ENTITY ncong SDATA "[ncong ]"--/ncong N: not congruent with--> <!ENTITY nequiv SDATA "[nequiv]"--/nequiv N: not identical with--> <!ENTITY ngE SDATA "[ngE ]"--/ngeqq N: not greater, dbl equals--> <!ENTITY nge SDATA "[nge ]"--/ngeq N: not greater-than-or-equal--> <!ENTITY nges SDATA "[nges ]"--/ngeqslant N: not gt-or-eq, slanted--> <!ENTITY ngt SDATA "[ngt ]"--/ngtr N: not greater-than--> <!ENTITY nle SDATA "[nle ]"--/nleq N: not less-than-or-equal--> <!ENTITY nlE SDATA "[nlE ]"--/nleqq N: not less, dbl equals--> <!ENTITY nles SDATA "[nles ]"--/nleqslant N: not less-or-eq, slant--> <!ENTITY nlt SDATA "[nlt ]"--/nless N: not less-than--> <!ENTITY nltri SDATA "[nltri ]"--/ntriangleleft N: not left triangle--> <!ENTITY nltrie SDATA "[nltrie]"--/ntrianglelefteq N: not l tri, eq--> <!ENTITY nmid SDATA "[nmid ]"--/nmid--> <!ENTITY npar SDATA "[npar ]"--/nparallel N: not parallel--> <!ENTITY npr SDATA "[npr ]"--/nprec N: not precedes--> <!ENTITY npre SDATA "[npre ]"--/npreceq N: not precedes, equals--> <!ENTITY nrtri SDATA "[nrtri ]"--/ntriangleright N: not rt triangle--> <!ENTITY nrtrie SDATA "[nrtrie]"--/ntrianglerighteq N: not r tri, eq--> <!ENTITY nsc SDATA "[nsc ]"--/nsucc N: not succeeds--> <!ENTITY nsce SDATA "[nsce ]"--/nsucceq N: not succeeds, equals--> <!ENTITY nsim SDATA "[nsim ]"--/nsim N: not similar--> <!ENTITY nsime SDATA "[nsime ]"--/nsimeq N: not similar, equals--> <!ENTITY nsmid SDATA "[nsmid ]"--/nshortmid--> <!ENTITY nspar SDATA "[nspar ]"--/nshortparallel N: not short par--> <!ENTITY nsub SDATA "[nsub ]"--/nsubset N: not subset--> <!ENTITY nsube SDATA "[nsube ]"--/nsubseteq N: not subset, equals--> <!ENTITY nsubE SDATA "[nsubE ]"--/nsubseteqq N: not subset, dbl eq--> <!ENTITY nsup SDATA "[nsup ]"--/nsupset N: not superset--> <!ENTITY nsupE SDATA "[nsupE ]"--/nsupseteqq N: not superset, dbl eq--> <!ENTITY nsupe SDATA "[nsupe ]"--/nsupseteq N: not superset, equals--> <!ENTITY nvdash SDATA "[nvdash]"--/nvdash N: not vertical, dash--> <!ENTITY nvDash SDATA "[nvDash]"--/nvDash N: not vertical, dbl dash--> <!ENTITY nVDash SDATA "[nVDash]"--/nVDash N: not dbl vert, dbl dash--> <!ENTITY nVdash SDATA "[nVdash]"--/nVdash N: not dbl vertical, dash--> <!ENTITY prnap SDATA "[prnap ]"--/precnapprox N: precedes, not approx--> <!ENTITY prnE SDATA "[prnE ]"--/precneqq N: precedes, not dbl eq--> <!ENTITY prnsim SDATA "[prnsim]"--/precnsim N: precedes, not similar--> <!ENTITY scnap SDATA "[scnap ]"--/succnapprox N: succeeds, not approx--> <!ENTITY scnE SDATA "[scnE ]"--/succneqq N: succeeds, not dbl eq--> <!ENTITY scnsim SDATA "[scnsim]"--/succnsim N: succeeds, not similar--> <!ENTITY subne SDATA "[subne ]"--/subsetneq N: subset, not equals--> <!ENTITY subnE SDATA "[subnE ]"--/subsetneqq N: subset, not dbl eq--> <!ENTITY supne SDATA "[supne ]"--/supsetneq N: superset, not equals--> <!ENTITY supnE SDATA "[supnE ]"--/supsetneqq N: superset, not dbl eq--> <!ENTITY vsubnE SDATA "[vsubnE]"--/subsetneqq N: subset not dbl eq, var--> <!ENTITY vsubne SDATA "[vsubne]"--/subsetneq N: subset, not eq, var--> <!ENTITY vsupne SDATA "[vsupne]"--/supsetneq N: superset, not eq, var--> <!ENTITY vsupnE SDATA "[vsupnE]"--/supsetneqq N: super not dbl eq, var--> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOamso PUBLIC "ISO 8879:1986//ENTITIES Added Math Symbols: Ordinary//EN"> %ISOamso; --> <!ENTITY ang SDATA "[ang ]"--/angle - angle--> <!ENTITY angmsd SDATA "[angmsd]"--/measuredangle - angle-measured--> <!ENTITY beth SDATA "[beth ]"--/beth - beth, Hebrew--> <!ENTITY bprime SDATA "[bprime]"--/backprime - reverse prime--> <!ENTITY comp SDATA "[comp ]"--/complement - complement sign--> <!ENTITY daleth SDATA "[daleth]"--/daleth - daleth, Hebrew--> <!ENTITY ell SDATA "[ell ]"--/ell - cursive small l--> <!ENTITY empty SDATA "[empty ]"--/emptyset /varnothing =small o, slash--> <!ENTITY gimel SDATA "[gimel ]"--/gimel - gimel, Hebrew--> <!ENTITY image SDATA "[image ]"--/Im - imaginary--> <!ENTITY inodot SDATA "[inodot]"--/imath =small i, no dot--> <!ENTITY jnodot SDATA "[jnodot]"--/jmath - small j, no dot--> <!ENTITY nexist SDATA "[nexist]"--/nexists - negated exists--> <!ENTITY oS SDATA "[oS ]"--/circledS - capital S in circle--> <!ENTITY planck SDATA "[planck]"--/hbar /hslash - Planck's over 2pi--> <!ENTITY real SDATA "[real ]"--/Re - real--> <!ENTITY sbsol SDATA "[sbsol ]"--/sbs - short reverse solidus--> <!ENTITY vprime SDATA "[vprime]"--/varprime - prime, variant--> <!ENTITY weierp SDATA "[weierp]"--/wp - Weierstrass p--> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOamsr PUBLIC "ISO 8879:1986//ENTITIES Added Math Symbols: Relations//EN"> %ISOamsr; --> <!ENTITY ape SDATA "[ape ]"--/approxeq R: approximate, equals--> <!ENTITY asymp SDATA "[asymp ]"--/asymp R: asymptotically equal to--> <!ENTITY bcong SDATA "[bcong ]"--/backcong R: reverse congruent--> <!ENTITY bepsi SDATA "[bepsi ]"--/backepsilon R: such that--> <!ENTITY bowtie SDATA "[bowtie]"--/bowtie R:--> <!ENTITY bsim SDATA "[bsim ]"--/backsim R: reverse similar--> <!ENTITY bsime SDATA "[bsime ]"--/backsimeq R: reverse similar, eq--> <!ENTITY bump SDATA "[bump ]"--/Bumpeq R: bumpy equals--> <!ENTITY bumpe SDATA "[bumpe ]"--/bumpeq R: bumpy equals, equals--> <!ENTITY cire SDATA "[cire ]"--/circeq R: circle, equals--> <!ENTITY colone SDATA "[colone]"--/coloneq R: colon, equals--> <!ENTITY cuepr SDATA "[cuepr ]"--/curlyeqprec R: curly eq, precedes--> <!ENTITY cuesc SDATA "[cuesc ]"--/curlyeqsucc R: curly eq, succeeds--> <!ENTITY cupre SDATA "[cupre ]"--/curlypreceq R: curly precedes, eq--> <!ENTITY dashv SDATA "[dashv ]"--/dashv R: dash, vertical--> <!ENTITY ecir SDATA "[ecir ]"--/eqcirc R: circle on equals sign--> <!ENTITY ecolon SDATA "[ecolon]"--/eqcolon R: equals, colon--> <!ENTITY eDot SDATA "[eDot ]"--/doteqdot /Doteq R: eq, even dots--> <!ENTITY esdot SDATA "[esdot ]"--/doteq R: equals, single dot above--> <!ENTITY efDot SDATA "[efDot ]"--/fallingdotseq R: eq, falling dots--> <!ENTITY egs SDATA "[egs ]"--/eqslantgtr R: equal-or-gtr, slanted--> <!ENTITY els SDATA "[els ]"--/eqslantless R: eq-or-less, slanted--> <!ENTITY erDot SDATA "[erDot ]"--/risingdotseq R: eq, rising dots--> <!ENTITY fork SDATA "[fork ]"--/pitchfork R: pitchfork--> <!ENTITY frown SDATA "[frown ]"--/frown R: down curve--> <!ENTITY gap SDATA "[gap ]"--/gtrapprox R: greater, approximate--> <!ENTITY gsdot SDATA "[gsdot ]"--/gtrdot R: greater than, single dot--> <!ENTITY gE SDATA "[gE ]"--/geqq R: greater, double equals--> <!ENTITY gel SDATA "[gel ]"--/gtreqless R: greater, equals, less--> <!ENTITY gEl SDATA "[gEl ]"--/gtreqqless R: gt, dbl equals, less--> <!ENTITY ges SDATA "[ges ]"--/geqslant R: gt-or-equal, slanted--> <!ENTITY Gg SDATA "[Gg ]"--/ggg /Gg /gggtr R: triple gtr-than--> <!ENTITY gl SDATA "[gl ]"--/gtrless R: greater, less--> <!ENTITY gsim SDATA "[gsim ]"--/gtrsim R: greater, similar--> <!ENTITY Gt SDATA "[Gt ]"--/gg R: dbl greater-than sign--> <!ENTITY lap SDATA "[lap ]"--/lessapprox R: less, approximate--> <!ENTITY ldot SDATA "[ldot ]"--/lessdot R: less than, with dot--> <!ENTITY lE SDATA "[lE ]"--/leqq R: less, double equals--> <!ENTITY lEg SDATA "[lEg ]"--/lesseqqgtr R: less, dbl eq, greater--> <!ENTITY leg SDATA "[leg ]"--/lesseqgtr R: less, eq, greater--> <!ENTITY les SDATA "[les ]"--/leqslant R: less-than-or-eq, slant--> <!ENTITY lg SDATA "[lg ]"--/lessgtr R: less, greater--> <!ENTITY Ll SDATA "[Ll ]"--/Ll /lll /llless R: triple less-than--> <!ENTITY lsim SDATA "[lsim ]"--/lesssim R: less, similar--> <!ENTITY Lt SDATA "[Lt ]"--/ll R: double less-than sign--> <!ENTITY ltrie SDATA "[ltrie ]"--/trianglelefteq R: left triangle, eq--> <!ENTITY mid SDATA "[mid ]"--/mid R:--> <!ENTITY models SDATA "[models]"--/models R:--> <!ENTITY pr SDATA "[pr ]"--/prec R: precedes--> <!ENTITY prap SDATA "[prap ]"--/precapprox R: precedes, approximate--> <!ENTITY pre SDATA "[pre ]"--/preceq R: precedes, equals--> <!ENTITY prsim SDATA "[prsim ]"--/precsim R: precedes, similar--> <!ENTITY rtrie SDATA "[rtrie ]"--/trianglerighteq R: right tri, eq--> <!ENTITY samalg SDATA "[samalg]"--/smallamalg R: small amalg--> <!ENTITY sc SDATA "[sc ]"--/succ R: succeeds--> <!ENTITY scap SDATA "[scap ]"--/succapprox R: succeeds, approximate--> <!ENTITY sccue SDATA "[sccue ]"--/succcurlyeq R: succeeds, curly eq--> <!ENTITY sce SDATA "[sce ]"--/succeq R: succeeds, equals--> <!ENTITY scsim SDATA "[scsim ]"--/succsim R: succeeds, similar--> <!ENTITY sfrown SDATA "[sfrown]"--/smallfrown R: small down curve--> <!ENTITY smid SDATA "[smid ]"--/shortmid R:--> <!ENTITY smile SDATA "[smile ]"--/smile R: up curve--> <!ENTITY spar SDATA "[spar ]"--/shortparallel R: short parallel--> <!ENTITY sqsub SDATA "[sqsub ]"--/sqsubset R: square subset--> <!ENTITY sqsube SDATA "[sqsube]"--/sqsubseteq R: square subset, equals--> <!ENTITY sqsup SDATA "[sqsup ]"--/sqsupset R: square superset--> <!ENTITY sqsupe SDATA "[sqsupe]"--/sqsupseteq R: square superset, eq--> <!ENTITY ssmile SDATA "[ssmile]"--/smallsmile R: small up curve--> <!ENTITY Sub SDATA "[Sub ]"--/Subset R: double subset--> <!ENTITY subE SDATA "[subE ]"--/subseteqq R: subset, dbl equals--> <!ENTITY Sup SDATA "[Sup ]"--/Supset R: dbl superset--> <!ENTITY supE SDATA "[supE ]"--/supseteqq R: superset, dbl equals--> <!ENTITY thkap SDATA "[thkap ]"--/thickapprox R: thick approximate--> <!ENTITY thksim SDATA "[thksim]"--/thicksim R: thick similar--> <!ENTITY trie SDATA "[trie ]"--/triangleq R: triangle, equals--> <!ENTITY twixt SDATA "[twixt ]"--/between R: between--> <!ENTITY vdash SDATA "[vdash ]"--/vdash R: vertical, dash--> <!ENTITY Vdash SDATA "[Vdash ]"--/Vdash R: dbl vertical, dash--> <!ENTITY vDash SDATA "[vDash ]"--/vDash R: vertical, dbl dash--> <!ENTITY veebar SDATA "[veebar]"--/veebar R: logical or, bar below--> <!ENTITY vltri SDATA "[vltri ]"--/vartriangleleft R: l tri, open, var--> <!ENTITY vprop SDATA "[vprop ]"--/varpropto R: proportional, variant--> <!ENTITY vrtri SDATA "[vrtri ]"--/vartriangleright R: r tri, open, var--> <!ENTITY Vvdash SDATA "[Vvdash]"--/Vvdash R: triple vertical, dash--> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISObox PUBLIC "ISO 8879:1986//ENTITIES Box and Line Drawing//EN"> %ISObox; --> <!-- All names are in the form: box1234, where: box = constants that identify a box drawing entity. 1&2 = v, V, u, U, d, D, Ud, or uD, as follows: v = vertical line for full height. u = upper half of vertical line. d = downward (lower) half of vertical line. 3&4 = h, H, l, L, r, R, Lr, or lR, as follows: h = horizontal line for full width. l = left half of horizontal line. r = right half of horizontal line. In all cases, an upper-case letter means a double or heavy line. --> <!ENTITY boxh SDATA "[boxh ]"--horizontal line --> <!ENTITY boxv SDATA "[boxv ]"--vertical line--> <!ENTITY boxur SDATA "[boxur ]"--upper right quadrant--> <!ENTITY boxul SDATA "[boxul ]"--upper left quadrant--> <!ENTITY boxdl SDATA "[boxdl ]"--lower left quadrant--> <!ENTITY boxdr SDATA "[boxdr ]"--lower right quadrant--> <!ENTITY boxvr SDATA "[boxvr ]"--upper and lower right quadrants--> <!ENTITY boxhu SDATA "[boxhu ]"--upper left and right quadrants--> <!ENTITY boxvl SDATA "[boxvl ]"--upper and lower left quadrants--> <!ENTITY boxhd SDATA "[boxhd ]"--lower left and right quadrants--> <!ENTITY boxvh SDATA "[boxvh ]"--all four quadrants--> <!ENTITY boxvR SDATA "[boxvR ]"--upper and lower right quadrants--> <!ENTITY boxhU SDATA "[boxhU ]"--upper left and right quadrants--> <!ENTITY boxvL SDATA "[boxvL ]"--upper and lower left quadrants--> <!ENTITY boxhD SDATA "[boxhD ]"--lower left and right quadrants--> <!ENTITY boxvH SDATA "[boxvH ]"--all four quadrants--> <!ENTITY boxH SDATA "[boxH ]"--horizontal line--> <!ENTITY boxV SDATA "[boxV ]"--vertical line--> <!ENTITY boxUR SDATA "[boxUR ]"--upper right quadrant--> <!ENTITY boxUL SDATA "[boxUL ]"--upper left quadrant--> <!ENTITY boxDL SDATA "[boxDL ]"--lower left quadrant--> <!ENTITY boxDR SDATA "[boxDR ]"--lower right quadrant--> <!ENTITY boxVR SDATA "[boxVR ]"--upper and lower right quadrants--> <!ENTITY boxHU SDATA "[boxHU ]"--upper left and right quadrants--> <!ENTITY boxVL SDATA "[boxVL ]"--upper and lower left quadrants--> <!ENTITY boxHD SDATA "[boxHD ]"--lower left and right quadrants--> <!ENTITY boxVH SDATA "[boxVH ]"--all four quadrants--> <!ENTITY boxVr SDATA "[boxVr ]"--upper and lower right quadrants--> <!ENTITY boxHu SDATA "[boxHu ]"--upper left and right quadrants--> <!ENTITY boxVl SDATA "[boxVl ]"--upper and lower left quadrants--> <!ENTITY boxHd SDATA "[boxHd ]"--lower left and right quadrants--> <!ENTITY boxVh SDATA "[boxVh ]"--all four quadrants--> <!ENTITY boxuR SDATA "[boxuR ]"--upper right quadrant--> <!ENTITY boxUl SDATA "[boxUl ]"--upper left quadrant--> <!ENTITY boxdL SDATA "[boxdL ]"--lower left quadrant--> <!ENTITY boxDr SDATA "[boxDr ]"--lower right quadrant--> <!ENTITY boxUr SDATA "[boxUr ]"--upper right quadrant--> <!ENTITY boxuL SDATA "[boxuL ]"--upper left quadrant--> <!ENTITY boxDl SDATA "[boxDl ]"--lower left quadrant--> <!ENTITY boxdR SDATA "[boxdR ]"--lower right quadrant--> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOdia PUBLIC "ISO 8879:1986//ENTITIES Diacritical Marks//EN"> %ISOdia; --> <!ENTITY acute SDATA "[acute ]"--=acute accent--> <!ENTITY breve SDATA "[breve ]"--=breve--> <!ENTITY caron SDATA "[caron ]"--=caron--> <!ENTITY cedil SDATA "[cedil ]"--=cedilla--> <!ENTITY circ SDATA "[circ ]"--=circumflex accent--> <!ENTITY dblac SDATA "[dblac ]"--=double acute accent--> <!ENTITY die SDATA "[die ]"--=dieresis--> <!ENTITY dot SDATA "[dot ]"--=dot above--> <!ENTITY grave SDATA "[grave ]"--=grave accent--> <!ENTITY macr SDATA "[macr ]"--=macron--> <!ENTITY ogon SDATA "[ogon ]"--=ogonek--> <!ENTITY ring SDATA "[ring ]"--=ring--> <!ENTITY tilde SDATA "[tilde ]"--=tilde--> <!ENTITY uml SDATA "[uml ]"--=umlaut mark--> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOgrk1 PUBLIC "ISO 8879:1986//ENTITIES Greek Letters//EN"> %ISOgrk1; --> <!ENTITY agr SDATA "[agr ]"--=small alpha, Greek--> <!ENTITY Agr SDATA "[Agr ]"--=capital Alpha, Greek--> <!ENTITY bgr SDATA "[bgr ]"--=small beta, Greek--> <!ENTITY Bgr SDATA "[Bgr ]"--=capital Beta, Greek--> <!ENTITY ggr SDATA "[ggr ]"--=small gamma, Greek--> <!ENTITY Ggr SDATA "[Ggr ]"--=capital Gamma, Greek--> <!ENTITY dgr SDATA "[dgr ]"--=small delta, Greek--> <!ENTITY Dgr SDATA "[Dgr ]"--=capital Delta, Greek--> <!ENTITY egr SDATA "[egr ]"--=small epsilon, Greek--> <!ENTITY Egr SDATA "[Egr ]"--=capital Epsilon, Greek--> <!ENTITY zgr SDATA "[zgr ]"--=small zeta, Greek--> <!ENTITY Zgr SDATA "[Zgr ]"--=capital Zeta, Greek--> <!ENTITY eegr SDATA "[eegr ]"--=small eta, Greek--> <!ENTITY EEgr SDATA "[EEgr ]"--=capital Eta, Greek--> <!ENTITY thgr SDATA "[thgr ]"--=small theta, Greek--> <!ENTITY THgr SDATA "[THgr ]"--=capital Theta, Greek--> <!ENTITY igr SDATA "[igr ]"--=small iota, Greek--> <!ENTITY Igr SDATA "[Igr ]"--=capital Iota, Greek--> <!ENTITY kgr SDATA "[kgr ]"--=small kappa, Greek--> <!ENTITY Kgr SDATA "[Kgr ]"--=capital Kappa, Greek--> <!ENTITY lgr SDATA "[lgr ]"--=small lambda, Greek--> <!ENTITY Lgr SDATA "[Lgr ]"--=capital Lambda, Greek--> <!ENTITY mgr SDATA "[mgr ]"--=small mu, Greek--> <!ENTITY Mgr SDATA "[Mgr ]"--=capital Mu, Greek--> <!ENTITY ngr SDATA "[ngr ]"--=small nu, Greek--> <!ENTITY Ngr SDATA "[Ngr ]"--=capital Nu, Greek--> <!ENTITY xgr SDATA "[xgr ]"--=small xi, Greek--> <!ENTITY Xgr SDATA "[Xgr ]"--=capital Xi, Greek--> <!ENTITY ogr SDATA "[ogr ]"--=small omicron, Greek--> <!ENTITY Ogr SDATA "[Ogr ]"--=capital Omicron, Greek--> <!ENTITY pgr SDATA "[pgr ]"--=small pi, Greek--> <!ENTITY Pgr SDATA "[Pgr ]"--=capital Pi, Greek--> <!ENTITY rgr SDATA "[rgr ]"--=small rho, Greek--> <!ENTITY Rgr SDATA "[Rgr ]"--=capital Rho, Greek--> <!ENTITY sgr SDATA "[sgr ]"--=small sigma, Greek--> <!ENTITY Sgr SDATA "[Sgr ]"--=capital Sigma, Greek--> <!ENTITY sfgr SDATA "[sfgr ]"--=final small sigma, Greek--> <!ENTITY tgr SDATA "[tgr ]"--=small tau, Greek--> <!ENTITY Tgr SDATA "[Tgr ]"--=capital Tau, Greek--> <!ENTITY ugr SDATA "[ugr ]"--=small upsilon, Greek--> <!ENTITY Ugr SDATA "[Ugr ]"--=capital Upsilon, Greek--> <!ENTITY phgr SDATA "[phgr ]"--=small phi, Greek--> <!ENTITY PHgr SDATA "[PHgr ]"--=capital Phi, Greek--> <!ENTITY khgr SDATA "[khgr ]"--=small chi, Greek--> <!ENTITY KHgr SDATA "[KHgr ]"--=capital Chi, Greek--> <!ENTITY psgr SDATA "[psgr ]"--=small psi, Greek--> <!ENTITY PSgr SDATA "[PSgr ]"--=capital Psi, Greek--> <!ENTITY ohgr SDATA "[ohgr ]"--=small omega, Greek--> <!ENTITY OHgr SDATA "[OHgr ]"--=capital Omega, Greek--> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOgrk2 PUBLIC "ISO 8879:1986//ENTITIES Monotoniko Greek//EN"> %ISOgrk2; --> <!ENTITY aacgr SDATA "[aacgr ]"--=small alpha, accent, Greek--> <!ENTITY Aacgr SDATA "[Aacgr ]"--=capital Alpha, accent, Greek--> <!ENTITY eacgr SDATA "[eacgr ]"--=small epsilon, accent, Greek--> <!ENTITY Eacgr SDATA "[Eacgr ]"--=capital Epsilon, accent, Greek--> <!ENTITY eeacgr SDATA "[eeacgr]"--=small eta, accent, Greek--> <!ENTITY EEacgr SDATA "[EEacgr]"--=capital Eta, accent, Greek--> <!ENTITY idigr SDATA "[idigr ]"--=small iota, dieresis, Greek--> <!ENTITY Idigr SDATA "[Idigr ]"--=capital Iota, dieresis, Greek--> <!ENTITY iacgr SDATA "[iacgr ]"--=small iota, accent, Greek--> <!ENTITY Iacgr SDATA "[Iacgr ]"--=capital Iota, accent, Greek--> <!ENTITY idiagr SDATA "[idiagr]"--=small iota, dieresis, accent, Greek--> <!ENTITY oacgr SDATA "[oacgr ]"--=small omicron, accent, Greek--> <!ENTITY Oacgr SDATA "[Oacgr ]"--=capital Omicron, accent, Greek--> <!ENTITY udigr SDATA "[udigr ]"--=small upsilon, dieresis, Greek--> <!ENTITY Udigr SDATA "[Udigr ]"--=capital Upsilon, dieresis, Greek--> <!ENTITY uacgr SDATA "[uacgr ]"--=small upsilon, accent, Greek--> <!ENTITY Uacgr SDATA "[Uacgr ]"--=capital Upsilon, accent, Greek--> <!ENTITY udiagr SDATA "[udiagr]"--=small upsilon, dieresis, accent, Greek--> <!ENTITY ohacgr SDATA "[ohacgr]"--=small omega, accent, Greek--> <!ENTITY OHacgr SDATA "[OHacgr]"--=capital Omega, accent, Greek--> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOgrk3 PUBLIC "ISO 8879:1986//ENTITIES Greek Symbols//EN"> %ISOgrk3; --> <!ENTITY alpha SDATA "[alpha ]"--=small alpha, Greek--> <!ENTITY beta SDATA "[beta ]"--=small beta, Greek--> <!ENTITY gamma SDATA "[gamma ]"--=small gamma, Greek--> <!ENTITY Gamma SDATA "[Gamma ]"--=capital Gamma, Greek--> <!ENTITY gammad SDATA "[gammad]"--/digamma--> <!ENTITY delta SDATA "[delta ]"--=small delta, Greek--> <!ENTITY Delta SDATA "[Delta ]"--=capital Delta, Greek--> <!ENTITY epsi SDATA "[epsi ]"--=small epsilon, Greek--> <!ENTITY epsiv SDATA "[epsiv ]"--/varepsilon--> <!ENTITY epsis SDATA "[epsis ]"--/straightepsilon--> <!ENTITY zeta SDATA "[zeta ]"--=small zeta, Greek--> <!ENTITY eta SDATA "[eta ]"--=small eta, Greek--> <!ENTITY thetas SDATA "[thetas]"--straight theta--> <!ENTITY Theta SDATA "[Theta ]"--=capital Theta, Greek--> <!ENTITY thetav SDATA "[thetav]"--/vartheta - curly or open theta--> <!ENTITY iota SDATA "[iota ]"--=small iota, Greek--> <!ENTITY kappa SDATA "[kappa ]"--=small kappa, Greek--> <!ENTITY kappav SDATA "[kappav]"--/varkappa--> <!ENTITY lambda SDATA "[lambda]"--=small lambda, Greek--> <!ENTITY Lambda SDATA "[Lambda]"--=capital Lambda, Greek--> <!ENTITY mu SDATA "[mu ]"--=small mu, Greek--> <!ENTITY nu SDATA "[nu ]"--=small nu, Greek--> <!ENTITY xi SDATA "[xi ]"--=small xi, Greek--> <!ENTITY Xi SDATA "[Xi ]"--=capital Xi, Greek--> <!ENTITY pi SDATA "[pi ]"--=small pi, Greek--> <!ENTITY piv SDATA "[piv ]"--/varpi--> <!ENTITY Pi SDATA "[Pi ]"--=capital Pi, Greek--> <!ENTITY rho SDATA "[rho ]"--=small rho, Greek--> <!ENTITY rhov SDATA "[rhov ]"--/varrho--> <!ENTITY sigma SDATA "[sigma ]"--=small sigma, Greek--> <!ENTITY Sigma SDATA "[Sigma ]"--=capital Sigma, Greek--> <!ENTITY sigmav SDATA "[sigmav]"--/varsigma--> <!ENTITY tau SDATA "[tau ]"--=small tau, Greek--> <!ENTITY upsi SDATA "[upsi ]"--=small upsilon, Greek--> <!ENTITY Upsi SDATA "[Upsi ]"--=capital Upsilon, Greek--> <!ENTITY phis SDATA "[phis ]"--/straightphi - straight phi--> <!ENTITY Phi SDATA "[Phi ]"--=capital Phi, Greek--> <!ENTITY phiv SDATA "[phiv ]"--/varphi - curly or open phi--> <!ENTITY chi SDATA "[chi ]"--=small chi, Greek--> <!ENTITY psi SDATA "[psi ]"--=small psi, Greek--> <!ENTITY Psi SDATA "[Psi ]"--=capital Psi, Greek--> <!ENTITY omega SDATA "[omega ]"--=small omega, Greek--> <!ENTITY Omega SDATA "[Omega ]"--=capital Omega, Greek--> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOgrk4 PUBLIC "ISO 8879:1986//ENTITIES Alternative Greek Symbols//EN"> %ISOgrk4; --> <!ENTITY b.alpha SDATA "[b.alpha ]"--=small alpha, Greek--> <!ENTITY b.beta SDATA "[b.beta ]"--=small beta, Greek--> <!ENTITY b.gamma SDATA "[b.gamma ]"--=small gamma, Greek--> <!ENTITY b.Gamma SDATA "[b.Gamma ]"--=capital Gamma, Greek--> <!ENTITY b.gammad SDATA "[b.gammad]"--/digamma--> <!ENTITY b.delta SDATA "[b.delta ]"--=small delta, Greek--> <!ENTITY b.Delta SDATA "[b.Delta ]"--=capital Delta, Greek--> <!ENTITY b.epsi SDATA "[b.epsi ]"--=small epsilon, Greek--> <!ENTITY b.epsiv SDATA "[b.epsiv ]"--/varepsilon--> <!ENTITY b.epsis SDATA "[b.epsis ]"--/straightepsilon--> <!ENTITY b.zeta SDATA "[b.zeta ]"--=small zeta, Greek--> <!ENTITY b.eta SDATA "[b.eta ]"--=small eta, Greek--> <!ENTITY b.thetas SDATA "[b.thetas]"--straight theta--> <!ENTITY b.Theta SDATA "[b.Theta ]"--=capital Theta, Greek--> <!ENTITY b.thetav SDATA "[b.thetav]"--/vartheta - curly or open theta--> <!ENTITY b.iota SDATA "[b.iota ]"--=small iota, Greek--> <!ENTITY b.kappa SDATA "[b.kappa ]"--=small kappa, Greek--> <!ENTITY b.kappav SDATA "[b.kappav]"--/varkappa--> <!ENTITY b.lambda SDATA "[b.lambda]"--=small lambda, Greek--> <!ENTITY b.Lambda SDATA "[b.Lambda]"--=capital Lambda, Greek--> <!ENTITY b.mu SDATA "[b.mu ]"--=small mu, Greek--> <!ENTITY b.nu SDATA "[b.nu ]"--=small nu, Greek--> <!ENTITY b.xi SDATA "[b.xi ]"--=small xi, Greek--> <!ENTITY b.Xi SDATA "[b.Xi ]"--=capital Xi, Greek--> <!ENTITY b.pi SDATA "[b.pi ]"--=small pi, Greek--> <!ENTITY b.Pi SDATA "[b.Pi ]"--=capital Pi, Greek--> <!ENTITY b.piv SDATA "[b.piv ]"--/varpi--> <!ENTITY b.rho SDATA "[b.rho ]"--=small rho, Greek--> <!ENTITY b.rhov SDATA "[b.rhov ]"--/varrho--> <!ENTITY b.sigma SDATA "[b.sigma ]"--=small sigma, Greek--> <!ENTITY b.Sigma SDATA "[b.Sigma ]"--=capital Sigma, Greek--> <!ENTITY b.sigmav SDATA "[b.sigmav]"--/varsigma--> <!ENTITY b.tau SDATA "[b.tau ]"--=small tau, Greek--> <!ENTITY b.upsi SDATA "[b.upsi ]"--=small upsilon, Greek--> <!ENTITY b.Upsi SDATA "[b.Upsi ]"--=capital Upsilon, Greek--> <!ENTITY b.phis SDATA "[b.phis ]"--/straightphi - straight phi--> <!ENTITY b.Phi SDATA "[b.Phi ]"--=capital Phi, Greek--> <!ENTITY b.phiv SDATA "[b.phiv ]"--/varphi - curly or open phi--> <!ENTITY b.chi SDATA "[b.chi ]"--=small chi, Greek--> <!ENTITY b.psi SDATA "[b.psi ]"--=small psi, Greek--> <!ENTITY b.Psi SDATA "[b.Psi ]"--=capital Psi, Greek--> <!ENTITY b.omega SDATA "[b.omega ]"--=small omega, Greek--> <!ENTITY b.Omega SDATA "[b.Omega ]"--=capital Omega, Greek--> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOlat1 PUBLIC "ISO 8879:1986//ENTITIES Added Latin 1//EN"> %ISOlat1; --> <!ENTITY aacute SDATA "[aacute]"--=small a, acute accent--> <!ENTITY Aacute SDATA "[Aacute]"--=capital A, acute accent--> <!ENTITY acirc SDATA "[acirc ]"--=small a, circumflex accent--> <!ENTITY Acirc SDATA "[Acirc ]"--=capital A, circumflex accent--> <!ENTITY agrave SDATA "[agrave]"--=small a, grave accent--> <!ENTITY Agrave SDATA "[Agrave]"--=capital A, grave accent--> <!ENTITY aring SDATA "[aring ]"--=small a, ring--> <!ENTITY Aring SDATA "[Aring ]"--=capital A, ring--> <!ENTITY atilde SDATA "[atilde]"--=small a, tilde--> <!ENTITY Atilde SDATA "[Atilde]"--=capital A, tilde--> <!ENTITY auml SDATA "[auml ]"--=small a, dieresis or umlaut mark--> <!ENTITY Auml SDATA "[Auml ]"--=capital A, dieresis or umlaut mark--> <!ENTITY aelig SDATA "[aelig ]"--=small ae diphthong (ligature)--> <!ENTITY AElig SDATA "[AElig ]"--=capital AE diphthong (ligature)--> <!ENTITY ccedil SDATA "[ccedil]"--=small c, cedilla--> <!ENTITY Ccedil SDATA "[Ccedil]"--=capital C, cedilla--> <!ENTITY eth SDATA "[eth ]"--=small eth, Icelandic--> <!ENTITY ETH SDATA "[ETH ]"--=capital Eth, Icelandic--> <!ENTITY eacute SDATA "[eacute]"--=small e, acute accent--> <!ENTITY Eacute SDATA "[Eacute]"--=capital E, acute accent--> <!ENTITY ecirc SDATA "[ecirc ]"--=small e, circumflex accent--> <!ENTITY Ecirc SDATA "[Ecirc ]"--=capital E, circumflex accent--> <!ENTITY egrave SDATA "[egrave]"--=small e, grave accent--> <!ENTITY Egrave SDATA "[Egrave]"--=capital E, grave accent--> <!ENTITY euml SDATA "[euml ]"--=small e, dieresis or umlaut mark--> <!ENTITY Euml SDATA "[Euml ]"--=capital E, dieresis or umlaut mark--> <!ENTITY iacute SDATA "[iacute]"--=small i, acute accent--> <!ENTITY Iacute SDATA "[Iacute]"--=capital I, acute accent--> <!ENTITY icirc SDATA "[icirc ]"--=small i, circumflex accent--> <!ENTITY Icirc SDATA "[Icirc ]"--=capital I, circumflex accent--> <!ENTITY igrave SDATA "[igrave]"--=small i, grave accent--> <!ENTITY Igrave SDATA "[Igrave]"--=capital I, grave accent--> <!ENTITY iuml SDATA "[iuml ]"--=small i, dieresis or umlaut mark--> <!ENTITY Iuml SDATA "[Iuml ]"--=capital I, dieresis or umlaut mark--> <!ENTITY ntilde SDATA "[ntilde]"--=small n, tilde--> <!ENTITY Ntilde SDATA "[Ntilde]"--=capital N, tilde--> <!ENTITY oacute SDATA "[oacute]"--=small o, acute accent--> <!ENTITY Oacute SDATA "[Oacute]"--=capital O, acute accent--> <!ENTITY ocirc SDATA "[ocirc ]"--=small o, circumflex accent--> <!ENTITY Ocirc SDATA "[Ocirc ]"--=capital O, circumflex accent--> <!ENTITY ograve SDATA "[ograve]"--=small o, grave accent--> <!ENTITY Ograve SDATA "[Ograve]"--=capital O, grave accent--> <!ENTITY oslash SDATA "[oslash]"--=small o, slash--> <!ENTITY Oslash SDATA "[Oslash]"--=capital O, slash--> <!ENTITY otilde SDATA "[otilde]"--=small o, tilde--> <!ENTITY Otilde SDATA "[Otilde]"--=capital O, tilde--> <!ENTITY ouml SDATA "[ouml ]"--=small o, dieresis or umlaut mark--> <!ENTITY Ouml SDATA "[Ouml ]"--=capital O, dieresis or umlaut mark--> <!ENTITY szlig SDATA "[szlig ]"--=small sharp s, German (sz ligature)--> <!ENTITY thorn SDATA "[thorn ]"--=small thorn, Icelandic--> <!ENTITY THORN SDATA "[THORN ]"--=capital THORN, Icelandic--> <!ENTITY uacute SDATA "[uacute]"--=small u, acute accent--> <!ENTITY Uacute SDATA "[Uacute]"--=capital U, acute accent--> <!ENTITY ucirc SDATA "[ucirc ]"--=small u, circumflex accent--> <!ENTITY Ucirc SDATA "[Ucirc ]"--=capital U, circumflex accent--> <!ENTITY ugrave SDATA "[ugrave]"--=small u, grave accent--> <!ENTITY Ugrave SDATA "[Ugrave]"--=capital U, grave accent--> <!ENTITY uuml SDATA "[uuml ]"--=small u, dieresis or umlaut mark--> <!ENTITY Uuml SDATA "[Uuml ]"--=capital U, dieresis or umlaut mark--> <!ENTITY yacute SDATA "[yacute]"--=small y, acute accent--> <!ENTITY Yacute SDATA "[Yacute]"--=capital Y, acute accent--> <!ENTITY yuml SDATA "[yuml ]"--=small y, dieresis or umlaut mark--> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOlat2 PUBLIC "ISO 8879:1986//ENTITIES Added Latin 2//EN"> %ISOlat2; --> <!ENTITY abreve SDATA "[abreve]"--=small a, breve--> <!ENTITY Abreve SDATA "[Abreve]"--=capital A, breve--> <!ENTITY amacr SDATA "[amacr ]"--=small a, macron--> <!ENTITY Amacr SDATA "[Amacr ]"--=capital A, macron--> <!ENTITY aogon SDATA "[aogon ]"--=small a, ogonek--> <!ENTITY Aogon SDATA "[Aogon ]"--=capital A, ogonek--> <!ENTITY cacute SDATA "[cacute]"--=small c, acute accent--> <!ENTITY Cacute SDATA "[Cacute]"--=capital C, acute accent--> <!ENTITY ccaron SDATA "[ccaron]"--=small c, caron--> <!ENTITY Ccaron SDATA "[Ccaron]"--=capital C, caron--> <!ENTITY ccirc SDATA "[ccirc ]"--=small c, circumflex accent--> <!ENTITY Ccirc SDATA "[Ccirc ]"--=capital C, circumflex accent--> <!ENTITY cdot SDATA "[cdot ]"--=small c, dot above--> <!ENTITY Cdot SDATA "[Cdot ]"--=capital C, dot above--> <!ENTITY dcaron SDATA "[dcaron]"--=small d, caron--> <!ENTITY Dcaron SDATA "[Dcaron]"--=capital D, caron--> <!ENTITY dstrok SDATA "[dstrok]"--=small d, stroke--> <!ENTITY Dstrok SDATA "[Dstrok]"--=capital D, stroke--> <!ENTITY ecaron SDATA "[ecaron]"--=small e, caron--> <!ENTITY Ecaron SDATA "[Ecaron]"--=capital E, caron--> <!ENTITY edot SDATA "[edot ]"--=small e, dot above--> <!ENTITY Edot SDATA "[Edot ]"--=capital E, dot above--> <!ENTITY emacr SDATA "[emacr ]"--=small e, macron--> <!ENTITY Emacr SDATA "[Emacr ]"--=capital E, macron--> <!ENTITY eogon SDATA "[eogon ]"--=small e, ogonek--> <!ENTITY Eogon SDATA "[Eogon ]"--=capital E, ogonek--> <!ENTITY gacute SDATA "[gacute]"--=small g, acute accent--> <!ENTITY gbreve SDATA "[gbreve]"--=small g, breve--> <!ENTITY Gbreve SDATA "[Gbreve]"--=capital G, breve--> <!ENTITY Gcedil SDATA "[Gcedil]"--=capital G, cedilla--> <!ENTITY gcirc SDATA "[gcirc ]"--=small g, circumflex accent--> <!ENTITY Gcirc SDATA "[Gcirc ]"--=capital G, circumflex accent--> <!ENTITY gdot SDATA "[gdot ]"--=small g, dot above--> <!ENTITY Gdot SDATA "[Gdot ]"--=capital G, dot above--> <!ENTITY hcirc SDATA "[hcirc ]"--=small h, circumflex accent--> <!ENTITY Hcirc SDATA "[Hcirc ]"--=capital H, circumflex accent--> <!ENTITY hstrok SDATA "[hstrok]"--=small h, stroke--> <!ENTITY Hstrok SDATA "[Hstrok]"--=capital H, stroke--> <!ENTITY Idot SDATA "[Idot ]"--=capital I, dot above--> <!ENTITY Imacr SDATA "[Imacr ]"--=capital I, macron--> <!ENTITY imacr SDATA "[imacr ]"--=small i, macron--> <!ENTITY ijlig SDATA "[ijlig ]"--=small ij ligature--> <!ENTITY IJlig SDATA "[IJlig ]"--=capital IJ ligature--> <!ENTITY inodot SDATA "[inodot]"--=small i without dot--> <!ENTITY iogon SDATA "[iogon ]"--=small i, ogonek--> <!ENTITY Iogon SDATA "[Iogon ]"--=capital I, ogonek--> <!ENTITY itilde SDATA "[itilde]"--=small i, tilde--> <!ENTITY Itilde SDATA "[Itilde]"--=capital I, tilde--> <!ENTITY jcirc SDATA "[jcirc ]"--=small j, circumflex accent--> <!ENTITY Jcirc SDATA "[Jcirc ]"--=capital J, circumflex accent--> <!ENTITY kcedil SDATA "[kcedil]"--=small k, cedilla--> <!ENTITY Kcedil SDATA "[Kcedil]"--=capital K, cedilla--> <!ENTITY kgreen SDATA "[kgreen]"--=small k, Greenlandic--> <!ENTITY lacute SDATA "[lacute]"--=small l, acute accent--> <!ENTITY Lacute SDATA "[Lacute]"--=capital L, acute accent--> <!ENTITY lcaron SDATA "[lcaron]"--=small l, caron--> <!ENTITY Lcaron SDATA "[Lcaron]"--=capital L, caron--> <!ENTITY lcedil SDATA "[lcedil]"--=small l, cedilla--> <!ENTITY Lcedil SDATA "[Lcedil]"--=capital L, cedilla--> <!ENTITY lmidot SDATA "[lmidot]"--=small l, middle dot--> <!ENTITY Lmidot SDATA "[Lmidot]"--=capital L, middle dot--> <!ENTITY lstrok SDATA "[lstrok]"--=small l, stroke--> <!ENTITY Lstrok SDATA "[Lstrok]"--=capital L, stroke--> <!ENTITY nacute SDATA "[nacute]"--=small n, acute accent--> <!ENTITY Nacute SDATA "[Nacute]"--=capital N, acute accent--> <!ENTITY eng SDATA "[eng ]"--=small eng, Lapp--> <!ENTITY ENG SDATA "[ENG ]"--=capital ENG, Lapp--> <!ENTITY napos SDATA "[napos ]"--=small n, apostrophe--> <!ENTITY ncaron SDATA "[ncaron]"--=small n, caron--> <!ENTITY Ncaron SDATA "[Ncaron]"--=capital N, caron--> <!ENTITY ncedil SDATA "[ncedil]"--=small n, cedilla--> <!ENTITY Ncedil SDATA "[Ncedil]"--=capital N, cedilla--> <!ENTITY odblac SDATA "[odblac]"--=small o, double acute accent--> <!ENTITY Odblac SDATA "[Odblac]"--=capital O, double acute accent--> <!ENTITY Omacr SDATA "[Omacr ]"--=capital O, macron--> <!ENTITY omacr SDATA "[omacr ]"--=small o, macron--> <!ENTITY oelig SDATA "[oelig ]"--=small oe ligature--> <!ENTITY OElig SDATA "[OElig ]"--=capital OE ligature--> <!ENTITY racute SDATA "[racute]"--=small r, acute accent--> <!ENTITY Racute SDATA "[Racute]"--=capital R, acute accent--> <!ENTITY rcaron SDATA "[rcaron]"--=small r, caron--> <!ENTITY Rcaron SDATA "[Rcaron]"--=capital R, caron--> <!ENTITY rcedil SDATA "[rcedil]"--=small r, cedilla--> <!ENTITY Rcedil SDATA "[Rcedil]"--=capital R, cedilla--> <!ENTITY sacute SDATA "[sacute]"--=small s, acute accent--> <!ENTITY Sacute SDATA "[Sacute]"--=capital S, acute accent--> <!ENTITY scaron SDATA "[scaron]"--=small s, caron--> <!ENTITY Scaron SDATA "[Scaron]"--=capital S, caron--> <!ENTITY scedil SDATA "[scedil]"--=small s, cedilla--> <!ENTITY Scedil SDATA "[Scedil]"--=capital S, cedilla--> <!ENTITY scirc SDATA "[scirc ]"--=small s, circumflex accent--> <!ENTITY Scirc SDATA "[Scirc ]"--=capital S, circumflex accent--> <!ENTITY tcaron SDATA "[tcaron]"--=small t, caron--> <!ENTITY Tcaron SDATA "[Tcaron]"--=capital T, caron--> <!ENTITY tcedil SDATA "[tcedil]"--=small t, cedilla--> <!ENTITY Tcedil SDATA "[Tcedil]"--=capital T, cedilla--> <!ENTITY tstrok SDATA "[tstrok]"--=small t, stroke--> <!ENTITY Tstrok SDATA "[Tstrok]"--=capital T, stroke--> <!ENTITY ubreve SDATA "[ubreve]"--=small u, breve--> <!ENTITY Ubreve SDATA "[Ubreve]"--=capital U, breve--> <!ENTITY udblac SDATA "[udblac]"--=small u, double acute accent--> <!ENTITY Udblac SDATA "[Udblac]"--=capital U, double acute accent--> <!ENTITY umacr SDATA "[umacr ]"--=small u, macron--> <!ENTITY Umacr SDATA "[Umacr ]"--=capital U, macron--> <!ENTITY uogon SDATA "[uogon ]"--=small u, ogonek--> <!ENTITY Uogon SDATA "[Uogon ]"--=capital U, ogonek--> <!ENTITY uring SDATA "[uring ]"--=small u, ring--> <!ENTITY Uring SDATA "[Uring ]"--=capital U, ring--> <!ENTITY utilde SDATA "[utilde]"--=small u, tilde--> <!ENTITY Utilde SDATA "[Utilde]"--=capital U, tilde--> <!ENTITY wcirc SDATA "[wcirc ]"--=small w, circumflex accent--> <!ENTITY Wcirc SDATA "[Wcirc ]"--=capital W, circumflex accent--> <!ENTITY ycirc SDATA "[ycirc ]"--=small y, circumflex accent--> <!ENTITY Ycirc SDATA "[Ycirc ]"--=capital Y, circumflex accent--> <!ENTITY Yuml SDATA "[Yuml ]"--=capital Y, dieresis or umlaut mark--> <!ENTITY zacute SDATA "[zacute]"--=small z, acute accent--> <!ENTITY Zacute SDATA "[Zacute]"--=capital Z, acute accent--> <!ENTITY zcaron SDATA "[zcaron]"--=small z, caron--> <!ENTITY Zcaron SDATA "[Zcaron]"--=capital Z, caron--> <!ENTITY zdot SDATA "[zdot ]"--=small z, dot above--> <!ENTITY Zdot SDATA "[Zdot ]"--=capital Z, dot above--> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOnum PUBLIC "ISO 8879:1986//ENTITIES Numeric and Special Graphic//EN"> %ISOnum; --> <!ENTITY half SDATA "[half ]"--=fraction one-half--> <!ENTITY frac12 SDATA "[frac12]"--=fraction one-half--> <!ENTITY frac14 SDATA "[frac14]"--=fraction one-quarter--> <!ENTITY frac34 SDATA "[frac34]"--=fraction three-quarters--> <!ENTITY frac18 SDATA "[frac18]"--=fraction one-eighth--> <!ENTITY frac38 SDATA "[frac38]"--=fraction three-eighths--> <!ENTITY frac58 SDATA "[frac58]"--=fraction five-eighths--> <!ENTITY frac78 SDATA "[frac78]"--=fraction seven-eighths--> <!ENTITY sup1 SDATA "[sup1 ]"--=superscript one--> <!ENTITY sup2 SDATA "[sup2 ]"--=superscript two--> <!ENTITY sup3 SDATA "[sup3 ]"--=superscript three--> <!ENTITY plus SDATA "[plus ]"--=plus sign B:-- > <!ENTITY plusmn SDATA "[plusmn]"--/pm B: =plus-or-minus sign--> <!ENTITY lt SDATA "[lt ]"--=less-than sign R:--> <!ENTITY equals SDATA "[equals]"--=equals sign R:--> <!ENTITY gt SDATA "[gt ]"--=greater-than sign R:--> <!ENTITY divide SDATA "[divide]"--/div B: =divide sign--> <!ENTITY times SDATA "[times ]"--/times B: =multiply sign--> <!ENTITY curren SDATA "[curren]"--=general currency sign--> <!ENTITY pound SDATA "[pound ]"--=pound sign--> <!ENTITY dollar SDATA "[dollar]"--=dollar sign--> <!ENTITY cent SDATA "[cent ]"--=cent sign--> <!ENTITY yen SDATA "[yen ]"--/yen =yen sign--> <!ENTITY num SDATA "[num ]"--=number sign--> <!ENTITY percnt SDATA "[percnt]"--=percent sign--> <!ENTITY amp SDATA "[amp ]"--=ampersand--> <!ENTITY ast SDATA "[ast ]"--/ast B: =asterisk--> <!ENTITY commat SDATA "[commat]"--=commercial at--> <!ENTITY lsqb SDATA "[lsqb ]"--/lbrack O: =left square bracket--> <!ENTITY bsol SDATA "[bsol ]"--/backslash =reverse solidus--> <!ENTITY rsqb SDATA "[rsqb ]"--/rbrack C: =right square bracket--> <!ENTITY lcub SDATA "[lcub ]"--/lbrace O: =left curly bracket--> <!ENTITY horbar SDATA "[horbar]"--=horizontal bar--> <!ENTITY verbar SDATA "[verbar]"--/vert =vertical bar--> <!ENTITY rcub SDATA "[rcub ]"--/rbrace C: =right curly bracket--> <!ENTITY micro SDATA "[micro ]"--=micro sign--> <!ENTITY ohm SDATA "[ohm ]"--=ohm sign--> <!ENTITY deg SDATA "[deg ]"--=degree sign--> <!ENTITY ordm SDATA "[ordm ]"--=ordinal indicator, masculine--> <!ENTITY ordf SDATA "[ordf ]"--=ordinal indicator, feminine--> <!ENTITY sect SDATA "[sect ]"--=section sign--> <!ENTITY para SDATA "[para ]"--=pilcrow (paragraph sign)--> <!ENTITY middot SDATA "[middot]"--/centerdot B: =middle dot--> <!ENTITY larr SDATA "[larr ]"--/leftarrow /gets A: =leftward arrow--> <!ENTITY rarr SDATA "[rarr ]"--/rightarrow /to A: =rightward arrow--> <!ENTITY uarr SDATA "[uarr ]"--/uparrow A: =upward arrow--> <!ENTITY darr SDATA "[darr ]"--/downarrow A: =downward arrow--> <!ENTITY copy SDATA "[copy ]"--=copyright sign--> <!ENTITY reg SDATA "[reg ]"--/circledR =registered sign--> <!ENTITY trade SDATA "[trade ]"--=trade mark sign--> <!ENTITY brvbar SDATA "[brvbar]"--=broken (vertical) bar--> <!ENTITY not SDATA "[not ]"--/neg /lnot =not sign--> <!ENTITY sung SDATA "[sung ]"--=music note (sung text sign)--> <!ENTITY excl SDATA "[excl ]"--=exclamation mark--> <!ENTITY iexcl SDATA "[iexcl ]"--=inverted exclamation mark--> <!ENTITY quot SDATA "[quot ]"--=quotation mark--> <!ENTITY apos SDATA "[apos ]"--=apostrophe--> <!ENTITY lpar SDATA "[lpar ]"--O: =left parenthesis--> <!ENTITY rpar SDATA "[rpar ]"--C: =right parenthesis--> <!ENTITY comma SDATA "[comma ]"--P: =comma--> <!ENTITY lowbar SDATA "[lowbar]"--=low line--> <!ENTITY hyphen SDATA "[hyphen]"--=hyphen--> <!ENTITY period SDATA "[period]"--=full stop, period--> <!ENTITY sol SDATA "[sol ]"--=solidus--> <!ENTITY colon SDATA "[colon ]"--/colon P:--> <!ENTITY semi SDATA "[semi ]"--=semicolon P:--> <!ENTITY quest SDATA "[quest ]"--=question mark--> <!ENTITY iquest SDATA "[iquest]"--=inverted question mark--> <!ENTITY laquo SDATA "[laquo ]"--=angle quotation mark, left--> <!ENTITY raquo SDATA "[raquo ]"--=angle quotation mark, right--> <!ENTITY lsquo SDATA "[lsquo ]"--=single quotation mark, left--> <!ENTITY rsquo SDATA "[rsquo ]"--=single quotation mark, right--> <!ENTITY ldquo SDATA "[ldquo ]"--=double quotation mark, left--> <!ENTITY rdquo SDATA "[rdquo ]"--=double quotation mark, right--> <!ENTITY nbsp SDATA "[nbsp ]"--=no break (required) space--> <!ENTITY shy SDATA "[shy ]"--=soft hyphen--> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOpub PUBLIC "ISO 8879:1986//ENTITIES Publishing//EN"> %ISOpub; --> <!ENTITY emsp SDATA "[emsp ]"--=em space--> <!ENTITY ensp SDATA "[ensp ]"--=en space (1/2-em)--> <!ENTITY emsp13 SDATA "[emsp3 ]"--=1/3-em space--> <!ENTITY emsp14 SDATA "[emsp4 ]"--=1/4-em space--> <!ENTITY numsp SDATA "[numsp ]"--=digit space (width of a number)--> <!ENTITY puncsp SDATA "[puncsp]"--=punctuation space (width of comma)--> <!ENTITY thinsp SDATA "[thinsp]"--=thin space (1/6-em)--> <!ENTITY hairsp SDATA "[hairsp]"--=hair space--> <!ENTITY mdash SDATA "[mdash ]"--=em dash--> <!ENTITY ndash SDATA "[ndash ]"--=en dash--> <!ENTITY dash SDATA "[dash ]"--=hyphen (true graphic)--> <!ENTITY blank SDATA "[blank ]"--=significant blank symbol--> <!ENTITY hellip SDATA "[hellip]"--=ellipsis (horizontal)--> <!ENTITY nldr SDATA "[nldr ]"--=double baseline dot (en leader)--> <!ENTITY frac13 SDATA "[frac13]"--=fraction one-third--> <!ENTITY frac23 SDATA "[frac23]"--=fraction two-thirds--> <!ENTITY frac15 SDATA "[frac15]"--=fraction one-fifth--> <!ENTITY frac25 SDATA "[frac25]"--=fraction two-fifths--> <!ENTITY frac35 SDATA "[frac35]"--=fraction three-fifths--> <!ENTITY frac45 SDATA "[frac45]"--=fraction four-fifths--> <!ENTITY frac16 SDATA "[frac16]"--=fraction one-sixth--> <!ENTITY frac56 SDATA "[frac56]"--=fraction five-sixths--> <!ENTITY incare SDATA "[incare]"--=in-care-of symbol--> <!ENTITY block SDATA "[block ]"--=full block--> <!ENTITY uhblk SDATA "[uhblk ]"--=upper half block--> <!ENTITY lhblk SDATA "[lhblk ]"--=lower half block--> <!ENTITY blk14 SDATA "[blk14 ]"--=25% shaded block--> <!ENTITY blk12 SDATA "[blk12 ]"--=50% shaded block--> <!ENTITY blk34 SDATA "[blk34 ]"--=75% shaded block--> <!ENTITY marker SDATA "[marker]"--=histogram marker--> <!ENTITY cir SDATA "[cir ]"--/circ B: =circle, open--> <!ENTITY squ SDATA "[squ ]"--=square, open--> <!ENTITY rect SDATA "[rect ]"--=rectangle, open--> <!ENTITY utri SDATA "[utri ]"--/triangle =up triangle, open--> <!ENTITY dtri SDATA "[dtri ]"--/triangledown =down triangle, open--> <!ENTITY star SDATA "[star ]"--=star, open--> <!ENTITY bull SDATA "[bull ]"--/bullet B: =round bullet, filled--> <!ENTITY squf SDATA "[squf ]"--/blacksquare =sq bullet, filled--> <!ENTITY utrif SDATA "[utrif ]"--/blacktriangle =up tri, filled--> <!ENTITY dtrif SDATA "[dtrif ]"--/blacktriangledown =dn tri, filled--> <!ENTITY ltrif SDATA "[ltrif ]"--/blacktriangleleft R: =l tri, filled--> <!ENTITY rtrif SDATA "[rtrif ]"--/blacktriangleright R: =r tri, filled--> <!ENTITY clubs SDATA "[clubs ]"--/clubsuit =club suit symbol--> <!ENTITY diams SDATA "[diams ]"--/diamondsuit =diamond suit symbol--> <!ENTITY hearts SDATA "[hearts]"--/heartsuit =heart suit symbol--> <!ENTITY spades SDATA "[spades]"--/spadesuit =spades suit symbol--> <!ENTITY malt SDATA "[malt ]"--/maltese =maltese cross--> <!ENTITY dagger SDATA "[dagger]"--/dagger B: =dagger--> <!ENTITY Dagger SDATA "[Dagger]"--/ddagger B: =double dagger--> <!ENTITY check SDATA "[check ]"--/checkmark =tick, check mark--> <!ENTITY cross SDATA "[ballot]"--=ballot cross--> <!ENTITY sharp SDATA "[sharp ]"--/sharp =musical sharp--> <!ENTITY flat SDATA "[flat ]"--/flat =musical flat--> <!ENTITY male SDATA "[male ]"--=male symbol--> <!ENTITY female SDATA "[female]"--=female symbol--> <!ENTITY phone SDATA "[phone ]"--=telephone symbol--> <!ENTITY telrec SDATA "[telrec]"--=telephone recorder symbol--> <!ENTITY copysr SDATA "[copysr]"--=sound recording copyright sign--> <!ENTITY caret SDATA "[caret ]"--=caret (insertion mark)--> <!ENTITY lsquor SDATA "[lsquor]"--=rising single quote, left (low)--> <!ENTITY ldquor SDATA "[ldquor]"--=rising dbl quote, left (low)--> <!ENTITY fflig SDATA "[fflig ]"--small ff ligature--> <!ENTITY filig SDATA "[filig ]"--small fi ligature--> <!ENTITY fjlig SDATA "[fjlig ]"--small fj ligature--> <!ENTITY ffilig SDATA "[ffilig]"--small ffi ligature--> <!ENTITY ffllig SDATA "[ffllig]"--small ffl ligature--> <!ENTITY fllig SDATA "[fllig ]"--small fl ligature--> <!ENTITY mldr SDATA "[mldr ]"--em leader--> <!ENTITY rdquor SDATA "[rdquor]"--rising dbl quote, right (high)--> <!ENTITY rsquor SDATA "[rsquor]"--rising single quote, right (high)--> <!ENTITY vellip SDATA "[vellip]"--vertical ellipsis--> <!ENTITY hybull SDATA "[hybull]"--rectangle, filled (hyphen bullet)--> <!ENTITY loz SDATA "[loz ]"--/lozenge - lozenge or total mark--> <!ENTITY lozf SDATA "[lozf ]"--/blacklozenge - lozenge, filled--> <!ENTITY ltri SDATA "[ltri ]"--/triangleleft B: l triangle, open--> <!ENTITY rtri SDATA "[rtri ]"--/triangleright B: r triangle, open--> <!ENTITY starf SDATA "[starf ]"--/bigstar - star, filled--> <!ENTITY natur SDATA "[natur ]"--/natural - music natural--> <!ENTITY rx SDATA "[rx ]"--pharmaceutical prescription (Rx)--> <!ENTITY sext SDATA "[sext ]"--sextile (6-pointed star)--> <!ENTITY target SDATA "[target]"--register mark or target--> <!ENTITY dlcrop SDATA "[dlcrop]"--downward left crop mark --> <!ENTITY drcrop SDATA "[drcrop]"--downward right crop mark --> <!ENTITY ulcrop SDATA "[ulcrop]"--upward left crop mark --> <!ENTITY urcrop SDATA "[urcrop]"--upward right crop mark --> <!-- (C) International Organization for Standardization 1986 Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. --> <!-- Character entity set. Typical invocation: <!ENTITY % ISOtech PUBLIC "ISO 8879:1986//ENTITIES General Technical//EN"> %ISOtech; --> <!ENTITY aleph SDATA "[aleph ]"--/aleph =aleph, Hebrew--> <!ENTITY and SDATA "[and ]"--/wedge /land B: =logical and--> <!ENTITY ang90 SDATA "[ang90 ]"--=right (90 degree) angle--> <!ENTITY angsph SDATA "[angsph]"--/sphericalangle =angle-spherical--> <!ENTITY ap SDATA "[ap ]"--/approx R: =approximate--> <!ENTITY becaus SDATA "[becaus]"--/because R: =because--> <!ENTITY bottom SDATA "[bottom]"--/bot B: =perpendicular--> <!ENTITY cap SDATA "[cap ]"--/cap B: =intersection--> <!ENTITY cong SDATA "[cong ]"--/cong R: =congruent with--> <!ENTITY conint SDATA "[conint]"--/oint L: =contour integral operator--> <!ENTITY cup SDATA "[cup ]"--/cup B: =union or logical sum--> <!ENTITY equiv SDATA "[equiv ]"--/equiv R: =identical with--> <!ENTITY exist SDATA "[exist ]"--/exists =at least one exists--> <!ENTITY forall SDATA "[forall]"--/forall =for all--> <!ENTITY fnof SDATA "[fnof ]"--=function of (italic small f)--> <!ENTITY ge SDATA "[ge ]"--/geq /ge R: =greater-than-or-equal--> <!ENTITY iff SDATA "[iff ]"--/iff =if and only if--> <!ENTITY infin SDATA "[infin ]"--/infty =infinity--> <!ENTITY int SDATA "[int ]"--/int L: =integral operator--> <!ENTITY isin SDATA "[isin ]"--/in R: =set membership--> <!ENTITY lang SDATA "[lang ]"--/langle O: =left angle bracket--> <!ENTITY lArr SDATA "[lArr ]"--/Leftarrow A: =is implied by--> <!ENTITY le SDATA "[le ]"--/leq /le R: =less-than-or-equal--> <!ENTITY minus SDATA "[minus ]"--B: =minus sign--> <!ENTITY mnplus SDATA "[mnplus]"--/mp B: =minus-or-plus sign--> <!ENTITY nabla SDATA "[nabla ]"--/nabla =del, Hamilton operator--> <!ENTITY ne SDATA "[ne ]"--/ne /neq R: =not equal--> <!ENTITY ni SDATA "[ni ]"--/ni /owns R: =contains--> <!ENTITY or SDATA "[or ]"--/vee /lor B: =logical or--> <!ENTITY par SDATA "[par ]"--/parallel R: =parallel--> <!ENTITY part SDATA "[part ]"--/partial =partial differential--> <!ENTITY permil SDATA "[permil]"--=per thousand--> <!ENTITY perp SDATA "[perp ]"--/perp R: =perpendicular--> <!ENTITY prime SDATA "[prime ]"--/prime =prime or minute--> <!ENTITY Prime SDATA "[Prime ]"--=double prime or second--> <!ENTITY prop SDATA "[prop ]"--/propto R: =is proportional to--> <!ENTITY radic SDATA "[radic ]"--/surd =radical--> <!ENTITY rang SDATA "[rang ]"--/rangle C: =right angle bracket--> <!ENTITY rArr SDATA "[rArr ]"--/Rightarrow A: =implies--> <!ENTITY sim SDATA "[sim ]"--/sim R: =similar--> <!ENTITY sime SDATA "[sime ]"--/simeq R: =similar, equals--> <!ENTITY square SDATA "[square]"--/square B: =square--> <!ENTITY sub SDATA "[sub ]"--/subset R: =subset or is implied by--> <!ENTITY sube SDATA "[sube ]"--/subseteq R: =subset, equals--> <!ENTITY sup SDATA "[sup ]"--/supset R: =superset or implies--> <!ENTITY supe SDATA "[supe ]"--/supseteq R: =superset, equals--> <!ENTITY there4 SDATA "[there4]"--/therefore R: =therefore--> <!ENTITY Verbar SDATA "[Verbar]"--/Vert =dbl vertical bar--> <!ENTITY angst SDATA "[angst ]"--Angstrom =capital A, ring--> <!ENTITY bernou SDATA "[bernou]"--Bernoulli function (script capital B)--> <!ENTITY compfn SDATA "[compfn]"--B: composite function (small circle)--> <!ENTITY Dot SDATA "[Dot ]"--=dieresis or umlaut mark--> <!ENTITY DotDot SDATA "[DotDot]"--four dots above--> <!ENTITY hamilt SDATA "[hamilt]"--Hamiltonian (script capital H)--> <!ENTITY lagran SDATA "[lagran]"--Lagrangian (script capital L)--> <!ENTITY lowast SDATA "[lowast]"--low asterisk--> <!ENTITY notin SDATA "[notin ]"--N: negated set membership--> <!ENTITY order SDATA "[order ]"--order of (script small o)--> <!ENTITY phmmat SDATA "[phmmat]"--physics M-matrix (script capital M)--> <!ENTITY tdot SDATA "[tdot ]"--three dots above--> <!ENTITY tprime SDATA "[tprime]"--triple prime--> <!ENTITY wedgeq SDATA "[wedgeq]"--R: corresponds to (wedge, equals)--> 40. DATA CONTENT NOTATION DECLARATIONS 40.1 Data content notation declarations. The following lists the PUBLIC data content notation declarations available for use in DoD publications conforming to this specification. Non-SGML entities used within a document must cite a data content notation within the document type declaration. To use any of these declarations, they must be contained within the document type declaration to be used. <!NOTATION cgmbin PUBLIC "ISO 8632/3//NOTATION CGM Binary text encoding//EN"> <!NOTATION iges PUBLIC "-//USA-DOD//NOTATION (ASME/ANSI Y14.26M-1987) Initial Graphics Exchange Specification//EN"> <!NOTATION fax PUBLIC "-//USA-DOD//NOTATION CCITT Group 4 Fascimile Type1 Untiled Raster//EN"> <!NOTATION faxtile PUBLIC "-//USA-DOD//NOTATION CCITT Group 4 Fascimile Type 2 Tiled Raster//EN" > 50. REPLACEMENT TEXT ENTITY DECLARATIONS 50.1 Replacement text entity declarations. The following lists the PUBLIC replacement text entity declarations available for use in DoD publications conforming to this specification. These entity declarations are listed separately and, in some cases, grouped into entity sets. Each separate declaration and each entity set have been assigned public identifiers by which they may be referenced in a declaration subset of a document type declaration. <!-- "STANDARD TEXT" ENTITIES --> <!-- The following entities provide standard text in the document element. They are typically used as the content of <notice> elements. Some contain entity references that must be declared appropriately within the document type declaration subset of each document in which they are used. --> <!-- The following entity declarations shall be associated with the public identifier: "-//USA-DOD//ENTITIES EFFECTIVE DATE NOTICE 900102//EN" To use and reference this entity set, use the following public entity declaration in the declaration subset of the document type declaration to be used, followed by a parameter entity reference to the public entity: <!ENTITY % efdate PUBLIC "-//USA-DOD//ENTITIES EFFECTIVE DATE NOTICE 900102//EN"> %efdate; --> <!ENTITY effdate "The effective date of this publication is &effdate1;. Instructions herein shall not be used prior to that date."> <!ENTITY effdate1 "Originator Supplies Effective Date Here"> <!-- The following entity declarations shall be associated with the public identifier: "-//USA-DOD//ENTITIES DISCLOSURE NOTICE 900102//EN" To use and reference this entity set, use the following public entity declaration in the declaration subset of the document type declaration to be used, followed by a parameter entity reference to the public entity: <!ENTITY % dsclos PUBLIC "-//USA-DOD//ENTITIES DISCLOSURE NOTICE 900102//EN"> %dsclos; --> <!ENTITY disclos "If this technical manual is approved for release to a foreign government, it is furnished upon the condition that it will not be released to another nation without specific authority of the &disclos1; of the United States, that it will be used for military purposes only, that individual or corporate rights originating in the information, whether patented or not will be respected, that the recipient will report promptly to the US, any known or suspected compromise, and that the information will be provided substantially the same degree of security afforded it by the Department of Defense of the United States."> <!ENTITY disclos1 "Originator Supplies Appropriate Dept or Agency Here"> <!-- The following entity declarations shall be associated with the public identifier: "-//USA-DOD//ENTITIES CLASSIFIED PAGES NOTICE 900102//EN" To use and reference this entity set, use the following public entity declaration in the declaration subset of the document type declaration to be used, followed by a parameter entity reference to the public entity: <!ENTITY % pgclas PUBLIC "-//USA-DOD//ENTITIES CLASSIFIED PAGES NOTICE 900102//EN"> %pgclas; --> <!ENTITY pgclass "This publication consists of &pgclass1; secret pages of &pgclass2; total pages."> <!ENTITY pgclass1 "Supply Number of Secret Pages Here"> <!ENTITY pgclass2 "Supply Total Number of Pages Here"> <!-- The following entity declarations shall be associated with the public identifier: "-//USA-DOD//ENTITIES NUMBER OF COPIES NOTICE 900102//EN" To use and reference this entity set, use the following public entity declaration in the declaration subset of the document type declaration to be used, followed by a parameter entity reference to the public entity: <!ENTITY % copynum PUBLIC "-//USA-DOD//ENTITIES NUMBER OF COPIES NOTICE 900102//EN"> %copynum; --> <!ENTITY copyno "Copy No. &pgclass3; of &pgclass4; copies."> <!ENTITY pgclass3 "_____"> <!ENTITY pgclass4 "_____"> <!-- The following entity declarations shall be associated with the public identifier: "-//USA-DOD//ENTITIES USAGE NOTICE 900102//EN" To use and reference this entity set, use the following public entity declaration in the declaration subset of the document type declaration to be used, followed by a parameter entity reference to the public entity: <!ENTITY % usage PUBLIC "-//USA-DOD//ENTITIES USAGE NOTICE 900102//EN"> %usage; --> <!ENTITY fouo "For Official Use Only"> <!ENTITY fcuo "For Consortium Use Only"> <!ENTITY fmuo "For MAP Use Only"> <!-- The following entity declarations shall be associated with the public identifier: "-//USA-DOD//ENTITIES DISTRIBUTION NOTICE 900102//EN" To use and reference this entity set, use the following public entity declaration in the declaration subset of the document type declaration to be used, followed by a parameter entity reference to the public entity: <!ENTITY % distrb PUBLIC "-//USA-DOD//ENTITIES DISTRIBUTION NOTICE 900102//EN"> %distrb; --> <!ENTITY distrib "This publication is required for official use or for administrative or operational purposes only. Distribution is limited to U.S. Government Agencies. Other requests for this document must be referred to &distrib1;."> <!ENTITY distrib1 "Originator Supplies Applicable Activity or Address Here"> <!-- The following entity declarations shall be associated with the public identifier: "-//USA-DOD//ENTITIES SUPERSEDURE NOTICE 900102//EN" To use and reference this entity set, use the following public entity declaration in the declaration subset of the document type declaration to be used, followed by a parameter entity reference to the public entity: <!ENTITY % super PUBLIC "-//USA-DOD//ENTITIES SUPERSEDURE NOTICE 900102//EN"> %super; --> <!ENTITY sprsede "This manual supersedes &sprsede1; dated &sprsede2;, which shall be destroyed in accordance with applicable security regulations."> <!ENTITY sprsede1 "Originator Supplies Superseded Publication Number Here"> <!ENTITY sprsede2 "Originator Supplies Supersedure Date Here"> <!-- The following entity declarations shall be associated with the public identifier: "-//USA-DOD//ENTITIES PRELIMINARY SUPERSEDURE NOTICE 900102//EN" To use and reference this entity set, use the following public entity declaration in the declaration subset of the document type declaration to be used, followed by a parameter entity reference to the public entity: <!ENTITY % prsuper PUBLIC "-//USA-DOD//ENTITIES PRELIMINARY SUPERSEDURE NOTICE 900102//EN"> %prsuper; --> <!ENTITY sprpre "This manual supersedes preliminary &sprpre1; dated &sprpre2;."> <!ENTITY sprpre1 "Originator Supplies Superseded Preliminary Publication Number Here"> <!ENTITY sprpre2 "Originator Supplies Supersedure Date Here"> <!-- The following entity declarations shall be associated with the public identifier: "-//USA-DOD//ENTITIES MIL-M-63036 TEXT ENTITIES 900102//EN" To use and reference this entity set, use the following public entity declaration in the declaration subset of the document type declaration to be used, followed by a parameter entity reference to the public entity: <!ENTITY % e63036 PUBLIC "-//USA-DOD//ENTITIES MIL-M-63036 TEXT ENTITIES 900102//EN"> %e63036; --> <!-- maintenance form text --> <!ENTITY maint "Department of the Army forms and procedures used for equipment maintenance will be those prescribed by TM 38-750, The Army Maintenance Management System (TAMMS)."> <!-- hand receipt text --> <!ENTITY hand "This manual has a companion document with a TM number followed by `-HR' (which stands for Hand Receipt). The &hand1; consists of preprinted hand receipts (DA form 2062) that list end item related equipment (i.e. COEI, BII and AAL) you must account for. As an aid to property accountability, additional -HR manuals may be requisitioned from the following source in accordance with procedures in Chapter 3, AR 310-2: &hand2;."> <!ENTITY hand1 "Hand receipt number"> <!ENTITY hand2 "Address of Adjutant General Publications Center"> <!-- Equipment Improvement Recommendations text --> <!ENTITY eir "If your &eir1; needs improvement, let us know. Send us an EIR. You, the user, are the only one who can tell us what you don't like about your equipment. Let us know why you don't like the design or performance. Put it on an SF 368 (Quality Deficiency Report). Mail it to us at &eir2;. We'll send you a reply."> <!ENTITY eir1 "originator to supply short equipment name"> <!ENTITY eir2 "originator supply address of proponent activity"> <!-- operation note --> <!ENTITY opnote "If the equipment must be kept in continuous operation, check and service only those items that can be checked and serviced without disturbing operation. Make the complete checks and services when the equipment can be shut down."> <!-- troubleshooting table text --> <!ENTITY trouble "The table lists the common malfunctions which you may find during the operation or maintenance of the &trouble1 or its components. You perform the tests/inspections and corrective actions in the order listed."> <!ENTITY trouble2 "This manual cannot list all malfunctions that may occur, nor all tests or inspections and corrective actions. If a malfunction is not listed or is not corrected by listed corrective actions, notify your supervisor."> <!ENTITY trouble1 "Originator supply name of equipment here"> <!-- The following entity declarations shall be associated with the public identifier: "-//USA-DOD//ENTITIES MIL-M-63038 TEXT ENTITIES 900102//EN" To use and reference this entity set, use the following public entity declaration in the declaration subset of the document type declaration to be used, followed by a parameter entity reference to the public entity: <!ENTITY % e63038 PUBLIC "-//USA-DOD//ENTITIES MIL-M-63038 TEXT ENTITIES 900102//EN"> %e63038; --> <!-- maintenance form text --> <!ENTITY maint "Department of the Army forms and procedures used for equipment maintenance will be those prescribed by TM 38-750, The Army Maintenance Management System."> <!-- accident text --> <!ENTITY accidnt "Accidents involving injuring to personnel or damage to materiel will be reported on DA Form 285 (Accident Report) in accordance with AR385-40. Explosives and ammunition malfunctions will be reported in accordance with AR75-1."> <!-- The following entity declarations shall be associated with the public identifier: "-//USA-DOD//ENTITIES MIL-M-63041 TEXT ENTITIES 900102//EN" To use and reference this entity set, use the following public entity declaration in the declaration subset of the document type declaration to be used, followed by a parameter entity reference to the public entity: <!ENTITY % e63041 PUBLIC "-//USA-DOD//ENTITIES MIL-M-63041 TEXT ENTITIES 900102//EN"> %e63041; --> <!-- scope info --> <!ENTITY scope "These instructions are for use by depot/contractor personnel. They apply to the &scope1; and in case of conflict take precedence over all other documents pertinent to depot maintenance of the item. Condition of overhauled &scope2; shall be that utility and performance is equal to that of a condition code A as defined in AR 725-50."> <!ENTITY scope1 "originator to fill in name of equipment here"> <!ENTITY scope2 "originator to fill in name of component/subassembly here"> <!-- equipment improvement recommendation text --> <!ENTITY eir "EIR will be prepared using SF 368, Quality Deficiency Report (QDR). Instructions for preparing QDR's are provided in DA PAM 738-750, The Army Maintenance Management System (TAMMS) or DA PAM 738-751, The Army Maintenance Management System (TAMMS) - Aircraft. Mail them to &eir1;. A reply will be furnished directly." > <!ENTITY eir1 "address of procuring agency to be supplied here"> <!-- Engineering Change Proposal text --> <!ENTITY ecp "ECP's will be prepared using DD form 1693, Engineering change proposal. Instructions for preparing ECPs are provided in MIL-STD-481, configuration control - engineering changes, deviations and waivers (short form). ECPs should be mailed direct to &ecp1;. A reply will be furnished directly to you."> <!ENTITY ecp1 "Originator supplies address of procuring activity here"> <!-- exception text --> <!ENTITY excp "When any work statement as set forth in this depot maintenance work requirement cannot be accomplished, or can only be accomplished in a manner other that specified, prior approval of the procuring activity shall be obtained by immediately submitting a request for deviation/waiver (RFD/W) in accordance with DOD-STD-480. Contractors will submit a RFD/W to the contracting officer."> <!-- data plate text --> <!ENTITY dataplt "When sufficient space is not available on the existing data plate to add information, the plate shall be replaced and all pertinent data transferred to the new plate. Data shall not be stamped directly on any part, assembly, or item of equipment except when approved by the government."> <!-- mobilization text --> <!ENTITY mobil "In the event of mobilization, all depot maintenance overhaul/repair procedure requirements, except those necessary to return the end item, assembly, subassembly, or component to a serviceable condition, are to be exempt or revised. The exemptions/revisions are identified in Appendix D. This appendix shall be provided by the procuring activity maintenance engineering group."> <!-- quality text --> <!ENTITY qual "Parts and material used for replacement, repair, or modifications shall meet the requirements of the equipment drawings and specifications if standards are not provided in the DWMR."> <!-- preshop analysis text --> <!ENTITY anal "The purpose of preshop analysis operations is to determine at the highest assembly level possible, the work required to return the &anal1; to a serviceable condition as specified in the DMWR. If inspection at the highest level of assembly is precluded by missing, damaged, or diagnosed defective assemblies, consideration will be given to techniques that would allow continued inspection at this level. If this is not possible, inspection will proceed at the next lower level. The preshop analysis checklist will be used to record the results of the analysis and any required maintenance."> <!ENTITY anal1 "Originator to supply name of equipment item"> <!-- inspection text --> <!ENTITY insp "All used components and refinished parts shall be examined 100 percent to determine serviceability in accordance with the limits, fits, and tolerances established in this DMWR." > <!-- responsibility text --> <!ENTITY respons "The contractor/depot is responsible for the accomplishment of the requirements described herein. The contractor/depot may utilize its own facilities or any other commercial laboratory acceptable to the procuring activity/commodity manager (PA/CM) for the performance of inspections and calibrations. The PA/CM reserves the right to perform the inspections to ensure that supplies or services conform to the prescribed requirements."> <!-- certification text --> <!ENTITY cert "The contractor/depot shall be responsible for ascertaining and certifying that personnel skills, procedures, processes, materials, and equipment identified below are used where required in the work process of this DMWR. Certification or like evidence will be maintained throughout the life of the contract: &certlst;."> <!ENTITY certlst "originator supplies list of certifications and requirements documents here"> <!ENTITY nocert "No certifications are required by the DWMR."> <!-- in process inspection text --> <!ENTITY inprcin "Minimum required in-process inspections are identified throughout this DMWR Additional inspections may be established by the contractor/depot as necessary."> <!-- The following text shall be associated with the public identifier: "-//USA-DOD//TEXT MIL-M-63041 QUALITY ASSURANCE TEXT ENTITY 900102//EN" Use the following public entity declaration in the declaration subset of the document type declaration to be used. To reference this entity in documents using the MIL-M-63041 document type declaration, use the entity reference below at the appropriate point in the text of the document. To use this entity in document using other document type declarations, the previous public entity declaration must be included in the declaration subset of the appropriate document type declaration. It may then be referenced with the entity reference below at the appropriate point in the text of the document. <!ENTITY % qa63041 PUBLIC "-//USA-DOD//TEXT MIL-M-63041 QUALITY ASSURANCE TEXT ENTITY 900102//EN"> %qa63041; --> <!-- quality assurance paragraph-including list 3.16.1.5 --> <para>The contractor/depot QA activity is responsible for preparing the QA/QC plan covering the work required by the DMWR and contract/work directive. Depots shall prepare the plan in accordance with DESCOM-R 702-1. Contractors shall conform to either MIL-Q-9858 for MIL-I-45208 as specified by the PA/CM. In addition to meeting the requirements of the foregoing references, the plan will provide that: <seqlist> <item>the QA/QC plan shall be made available to the PA/CM for review prior to the start of work and throughout the life of the program. The contractor shall notify the PA/CM in writing of any change. The basic plan and changes thereto are subject to disapproval by the PA/CM. <item>Comparison inspection standards are coordinated with the PA/CM Quality Assurance element. <item>Material or procedural departure from the DMWR or supporting specifications will not be accepted without prior approval of the PA/CM in accordance with MIL-STD-481. <item>Rejected material is randomly inspected to verify classification prior to reclamation or disposal. <item>Maintenance and reclamation procedures are verified before and periodically during operations. <item> Inspection requirements in Section II below are accomplished." </seqlist> </para> <!-- The following text shall be associated with the public identifier: "-//USA-DOD//TEXT MIL-M-63041 ACCEPTANCE INSPECTION TEXT ENTITY 900102//EN" Use the following public entity declaration in the declaration subset of the document type declaration to be used. To reference this entity in documents using the MIL-M-63041 document type declaration, use the entity reference below at the appropriate point in the text of the document. To use this entity in document using other document type declarations, the previous public entity declaration must be included in the declaration subset of the appropriate document type declaration. It may then be referenced with the entity reference below at the appropriate point in the text of the document. <!ENTITY % accinsp63041 PUBLIC "-//USA-DOD//TEXT MIL-M-63041 ACCEPTANCE INSPECTION TEXT ENTITY 900102//EN"> %accinsp63041; --> <!-- Acceptance inspection text 3.16.2.3 --> <para>Acceptance of all items processed in accordance with this DMWR will be based on the following: <seqlist> <item>Compliance with quality of material requirements. <item>Compliance with in-process inspections. <item>Compliance with the requirements of the final acceptance inspection and for the final assembly inspections. <item>Proper preparation for shipment/storage, if appropriate." </seqlist> </para> <!-- The following entity declarations shall be associated with the public identifier: "-//USA-DOD//ENTITIES MIL-M-6675 TEXT ENTITIES 900102//EN" To use and reference this entity set, use the following public entity declaration in the declaration subset of the document type declaration to be used, followed by a parameter entity reference to the public entity: <!ENTITY % e6675 PUBLIC "-//USA-DOD//ENTITIES MIL-M-6675 TEXT ENTITIES 900102//EN"> %e6675; --> <!-- text to be contained in foreword --> <!ENTITY fore "Some repair parts for the equipment covered in this manual are provided in the form of kits. Refer to the applicable Illustrated Parts Breakdown for detailed information on the contents of the kits. Activities shall replace all parts, regardless of condition, which are removed in the process of disassembly with all like parts furnished in the kit. Therefore, instructions for cleaning, inspecting and reworking such used parts have been omitted. If any parts in the kit must be cleaned, inspected, or tested prior to installation, instructions for performing these requirements are included in this manual. Naturally, all defective parts are to be replaced, but a part unnecessary to be removed in the process of disassembly shall not be removed solely for the purposed of replacement by a corresponding kitted part."> <!-- note preceding prefunctional checks table --> <!ENTITY pfcknote "NOTE: It is not necessary to perform the following prefunctional checks unless reported deficiency of equipment to be repaired indicated the internal shorted or open circuit exists." > <!-- note to follow disassembly instructions --> <!ENTITY disnote "Presence of a new part in the applicable kit eliminates the necessity of cleaning, inspecting, or reworking the equivalent used part removed from the assembly being repaired. The instructions which follow cover removed parts not supplied in kits and kitted parts (if any) which require cleaning, inspecting, or testing prior to installation."> <!-- The following text shall be associated with the public identifier: "-//USA-DOD//TEXT MIL-M-6675 STORAGE INSPECTION NOTE TEXT ENTITY 900102//EN" Use the following public entity declaration in the declaration subset of the document type declaration to be used. To reference this entity in documents using the MIL-M-6675 document type declaration, use the entity reference below at the appropriate point in the text of the document. To use this entity in document using other document type declarations, the previous public entity declaration must be included in the declaration subset of the appropriate document type declaration. It may then be referenced with the entity reference below at the appropriate point in the text of the document. <!ENTITY % stornote6675 PUBLIC "-//USA-DOD//TEXT MIL-M-6675 STORAGE INSPECTION NOTE TEXT ENTITY 900102//EN"> %stornote6675; --> <!-- storage inspection note: paragraph 3.10.13 --> <para0> <title>STORAGE INSPECTION. Different degrees of inspection are required based upon the type of storage: Ready storage: Equipment maintained in a completely ready status in anticipation of a relatively near term use requirement. This equipment may be positioned on the shelf, held in the shop, or may be installed in the next higher assembly or installation. The item may be pre-loaded with munitions and maintained in a munitions holding area or munitions storage igloo in preparation for installation on the aircraft. Equipment will be provided adequate protection from damage and the elements. Examples of ready storage would be DD 780 equipment receiving frequent use, and mobility contingency, or bare base assets requiring a high degree of readiness for immediate employment. Inspection criteria: Inspection interval for items in this manual, placed in ready storage will be that deemed necessary by the IM/SM to assure serviceability in "ready-to-use" condition. For weapons release equipment, the inspection frequency on items in ready storage will be a minimum of every eighteen months. Refer to Table X-X for ready storage inspection and maintenance requirements. Extended storage: These items maintained in a ready condition for which a far- term-utilization requirement exists but for which no requirements exists for frequent exercises or immediate short term employment. Equipment placed in extended storage will be in a serviceable, ready to use condition. This category includes WRM assets. Inspection criteria: An annual sampling inspection will be performed of 10 percent of assets in extended storage. Items inspected will be identified; marked to prevent redundant inspection of the same items during future annual inspections. Subsequent annual inspections will be performed on those items which have acquired the longest calendar year time period since last inspections. In the event that deterioration of equipment is detected during any annual inspection, a determination will be made whether an inspection of all assets having corresponding packaging dates must be performed. For field organizations, this determination will be made either by the organizational commander or maintenance supervisor. For AFLC depot organizations, this determination will be made by the supply inspector. Refer to Table X-X for extended storage inspection and maintenance requirements. Storage and packaging: Equipment placed in extended storage will meet the following criteria: Equipment will be packaged in accordance with applicable transportation packaging order. Packaged equipment must be warehoused in a covered structure which will provide protection >from climatic elements. Units which have been subjected to prior use must meet all criteria outlined in Table X-X prior to being placed in extended storage. Items received from depot or in base supply assets, meeting the packaging requirements specified in (a) above will be considered as being in extended storage." 60. PUBLIC TABLE DEFINITIONS 60.1 Public table definitions. The following lists the declarations defining tables to be used. Each has a public identifier that is declared in the appropriate document type declaration. These may be modified, in which case the public identifier is no longer used. The declarations that appear in this section are changed as required and repeated as system entities with the MIL-STD-1840 deliverable. Tool/Equipment Number Figure No. Nomenclature Use and Application Ref No. Chart No. Description Minimum Maximum Replacement Minimum/Maximum TROUBLE PROBABLE CAUSE CHECKOUT PROCEDURE AND REMEDIAL ACTION ITEM NO. INTERVAL ITEM TO BE INSPECTED Equipment is Not Ready/Available If: B D A PROCEDURE TYPICAL EQUIPMENT SPECIFICATION TYPE OF EQUIPMENT Hand and Portable Weapons Combat Vehicles Trucks Construction and Material Handling Equipment Generator Sets Comm and Elect Test and Diagnostic Equipment and Audio Visual Equip Component Acceptable Reparable Irreparable Item No. Item To Be Inspected Procedures Item No. Interval Item To Be Inspected Procedures W M Q S A B H MI LOCATION ITEM ACTION REMARKS Thread Size Minimum Breakaway Torque (In.-Lbs.) Thread Size Minimum Breakaway Torque (In.-Lbs.) Items Outer covering or body material and color Color of markings Height of letters (in.) Marking Part (Tool) Number Figure & Index No. Nomenclature Use Type Designation Alternate Type Designation Figure & Index No. Nomenclature Use Step Procedure Normal Indication Corrective Action Circuit Being Checked Value Part Being Checked NOMENCLATURE INSPECT FOR REPAIR READY STORAGE EXTENDED STORAGE Item Figure and Index No. Part Number Nomenclature Use and Application Item Figure and Index No. Nomenclature *AN Type Designation **Alternate Use and Application Item Part Number Specification Nomenclature Use and Application Step No. Symptom Probable Cause Corrective Action Part (Tool) Number Mfr Code or Name/Address Figure & Index No. Nomenclature Use TYPE DESIGNATION ALTERNATE TYPE DESIGNATION FIGURE & INDEX NO. NOMENCLATURE USE 70. MATH DECLARATION SET 70.1 Math declaration set. The following lists the declaration set defining a logical, SGML structure for describing mathematical formulae for use in in DoD publications conforming to this specification. 80. ELECTRONIC REVIEW DECLARATION SET 80.1 Electronic Review. The electronic review declaration set provides the required SGML structures for the review of SGML text documents electronically using SGML for the comments. (Note that this includes commenting on graphics and other entities at the level of the entire entity.) The capability supported by these structures enables reviewers located in diverse environments to make and exchange comments to multiple copies of a document file over a network. The comments may then be sorted, processed, and incorporated into the document by the "owner" system. 80.1.1 Electronic Review Process Improvement. This capability represents a process improvement over the traditional document development process: a. The use of SGML throughout the entire document development cycle eliminates "redline" paper copies and costly conversion cycles that typically occur during document development b. The benefits of the SGML intelligent markup remain accessible throughout c. Time required for delivery and review cycle is reduced d. Text and graphics are maintained in discrete files under their originating processes, facilitating reuse 80.1.2 Electronic Review Comments. Electronic review comments using SGML are distinguished >from comments made using proprietary vendor annotation capabilities by the following characteristics: a. The comments may be associated with elements at any level in the document structure b. The comments may be shared between different proprietary platforms c. The comments are machine-processable for a variety of purposes, some of which may be user- defined 80.1.3 Electronic Review Declaration Set Overview. The electronic review declaration set consists of a portable electronic review "toolkit" suitable for incorporation into any document type declaration, for use in review of any document instance of that type. The structures have been defined as generically as possible, in order to take many kinds of review into account: e.g., internal contractor reviews, Government reviews, contractor/Government reviews, and specification reviews. Provision has been made for the definition of user-defined values for categories of review information. Additional thought has been given to processing scenarios involving use of the declaration set on a range of platforms, with automation of functions supported by the SGML structures varying to great degree. Consequently, the declaration set has been designed to support the preparation of comments (modification requests, or modreqs ) that may be stored in either of the following ways: a. Within a modification request-only document that references the base document instance b. Within the base document instance to which the modification request(s) refers 80.2 Electronic Review Declaration Set. The following lists the declaration set defining the required SGML structures for the review of SGML text documents electronically using SGML for the comments (modification requests). This declaration set may optionally be used in the review of DoD publications conforming to this specification. 80.3 Using the Electronic Review Toolkit. The electronic review declaration set consists of a stand-alone "toolkit" that may be referenced as a public entity for use with a given document type declaration, with little or no change to that document type declaration. Use of the toolkit requires: 1) Unique identifiers on elements (at least to the level of granularity included in the review) 2) Redefinition of the document level element via parameterization An example of referencing the electronic review toolkit for use with the MIL-M-28001 example DTD, without change to the publicly registered DTD, is as follows: %ereview; ]> Cases in which a fine-grained review is required may necessitate adding more "id" attributes to a publicly registered DTD. It is presumed that any such changes would be made to a working version, however, without impact on final deliveries. In cases involving very large documents, it may be necessary to have a temporary SGML declaration that accompanies the temporary working DTD, in order to accommodate the ID Capacity (IDCAP) and/or the IDREF Capacity (IDREFCAP). 80.4 Electronic Review Functionality. Examples of functionality that can be supported by the modification request structures are as follows: a. Sorting of all comments to a given text element. (Note that this processing adds a requirement to the development of the base document instance: the assignment of unique identifiers to all document elements with which reviewers may be required to associate comments.) b. Sorting the comments on the basis of comment ID information: e.g., reviewer, date, organization, priority, classification, and category. c. Sorting comments related to a particular user-defined topic or concept. d. Tracking the comments on the basis of configuration/version information about the comments, and compiling a "history" file of comments (including disposition and status) from a given review, or from all reviews of a given document. e. Tracking comments on comments. f. Tracking the "disposition" determined as appropriate for each comment by the responsible organization. g. In the case of new text, replacement text, or a deletion being proposed by a reviewer, supporting the following: 1) marking in some manner (e.g., highlighting) the precise portion of the identified element that is to be affected by the change, and 2) tracking the location information in the modreq. In the case of a modreq proposing new text, replacement text, or a deletion that is being evaluated by a document owner, displaying the precise area affected by the change on the receiving system, on the basis of the location information in the modreq. h. In the case of general modifications to a document being proposed by reviewers (any proposed changes other than ones in which specific proposed new text or replacement text is suggested), sorting the general modifications for evaluation and manual processing by the responsible organization. i. Tracking the status of the owner organization's response to the comment. 80.5 Electronic Review User Interface. While the modreq declaration set may be used with only minimal automation, it can support user interfaces providing a high degree of automation of the electronic review functions. For example, in the case where modreqs are written to a separate modreq- only file, the declaration set could support a window application which prompts the user to fill in a template with information for a particular modreq, hiding the tags. Similarly, attribute values for the modreq might be set via menu selections or use of a dialogue box. In the case where modreqs are stored in the document instance, the declaration set might support automated suppression/deletion of the modreqs prior to final CDRL delivery. In either case, features for configuration control of the modreqs could include a data base of modreqs which could be compiled into a history file for a given review or for all reviews of the document. 80.6 Electronic Review Process. While the details of the electronic review process are not specified, implementors will find it helpful to keep in mind a typical process for the review of an SGML text document over an electronic network using SGML for the comments, as described below. Notice that clear distinction between the two required roles of document reviewer and document owner is critical to the smooth conduct of electronic review. Also note that extremely fine details of timing offer numerous possibilities, to be determined by the implementation. a. The "owner" of the review document (e.g., organization or author) establishes those attribute values for a modreq that are designed to be user-defined, then documents and distributes these values as the operative attribute values for a given review or for general use, along with any other review procedures required. b. The owner of the review document instance assigns unique identifiers to every element (or to every element included in the review, since use of the SGML electronic review capability requires unique identifiers on elements). This assignment of unique identifiers may be automated or semi-automated by implementations of vendor software. c. A copy of the review document is transmitted electronically over a network, or made accessible via a distributed file system, to the "receiving" organization(s) or individual(s). d. The reviewer brings up the document on the receiving system, most likely in read-only form, and begins the process of evaluation. e. The reviewer writes modreqs, and optionally provides reasons for the following types of proposed changes to the review document: 1) Change text, which consists of new text, replacement text, or a text element deletion, or 2) A general modification to the document (i.e., any proposed change other than one in which specific new text, replacement text, or a deletion is suggested). In either case, a unique identifier is assigned to each modreq, and the appropriate attribute values are set for the review information for each modreq. Where the implementation allows, the modreqs are written to a separate modreq-only file. Optionally, the modreqs may also be stored within the review document instance (the actual content of the review document that contains the modreqs is not changed). f. The receiving system transmits electronically (or makes accessible via a distributed file system) to the owner system the modreq-only file, or, optionally, the review document in which modreqs have been embedded. g. In the case of modreqs transmitted by multiple reviewers, the owner system performs ID resolution of the various types of IDs assigned to the modreqs. (Alternatively, a common convention for the creation of modreq IDs should be promulgated by the "owner" organization prior to commencement of the review.) h. The owner evaluates the modreqs, determining 1) the disposition for each and 2) the initial status of the response to each. The corresponding attribute values are then set. i. The owner organization incorporates the comments as appropriate, thereby creating the new version of the base document. This is accomplished either by automated incorporation of new text, replacement text, or a text element deletion for which an "approved" status is indicated, or by manual incorporation of changes resulting from an approved general modification. j. The history file for the modreqs is updated with the final status of each modreq from the review. Acquisition requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Additional final deliverable . . . . . . . . . . . . . . . . . . . . . . 18 ALPHABETICAL LISTING OF ATTRIBUTE DESCRIPTIONS . . . . . . . . . . . . .161 ALPHABETICAL LISTING OF TAG DESCRIPTIONS . . . . . . . . . . . . . . . . 73 APPLICABLE DOCUMENTS . . . . . . . . . . . . . . . . . . . .3, 25, 173, 310 Application of non-Government standards. . . . . . . . . . . . . . . . . 10 Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240 Attribute (definition) list declaration. . . . . . . . . . . . . . . . . 20 Attribute (of an element). . . . . . . . . . . . . . . . . . . . . . . . 19 Attribute (specification) list . . . . . . . . . . . . . . . . . . . . . 20 Attribute definition . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Attribute list declaration . . . . . . . . . . . . . . . . . . . . . . . 34 Attribute name . . . . . . . . . . . . . . . . . . . . . . . . . . . . .304 Attribute Set Descriptions . . . . . . . . . . . . . . . . . . . . .73, 161 Attribute Type Column. . . . . . . . . . . . . . . . . . . . . . . . . .161 Available space. . . . . . . . . . . . . . . . . . . . . . . . . . . . .240 Baseline publication types . . . . . . . . . . . . . . . . . . . . . . . 10 Best match algorithm . . . . . . . . . . . . . . . . . . . . . . . . . .180 Best match evaluation. . . . . . . . . . . . . . . . . . . . . . . . . .182 Best matching e-i-c. . . . . . . . . . . . . . . . . . . . . . . . . . .180 Border . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217, 304 Border specification . . . . . . . . . . . . . . . . . . . . . . . . . .268 Bottom margin area . . . . . . . . . . . . . . . . . . . . . . . . . . .257 Boxing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222 Change mark. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208 Change mark area . . . . . . . . . . . . . . . . . . . . . . . . . . . .258 Changes from previous issue. . . . . . . . . . . . . . . . . . . . . . . 23 Character fill . . . . . . . . . . . . . . . . . . . . . . . . . . 195, 304 CHARACTER SET ENTITY DECLARATIONS. . . . . . . . . . . . . . . . . . . .311 Characteristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . .304 Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . 176, 201 Choosing the appropriate document type declaration set . . . . . . . . . 38 Cognizance of source DTD . . . . . . . . . . . . . . . . . . . . . . . .287 Color. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192 Column area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260 Column characteristics . . . . . . . . . . . . . . . . . . . . . . . . .266 Composition - graphics . . . . . . . . . . . . . . . . . . . . . . . . .239 Composition characteristics. . . . . . . . . . . . . . . . . . . . . . .176 Composition characteristics and logical elements . . . . . . . . . . . .176 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 16, 239, 254 Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179, 304 Context characteristic syntax. . . . . . . . . . . . . . . . . . . . . .179 Coordinate, world system . . . . . . . . . . . . . . . . . . . . . . . .304 Coordinating the Use of the Appendixes . . . . . . . . . . . . . . . . . 43 Counter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196 DATA CONTENT NOTATION DECLARATIONS . . . . . . . . . . . . . . . . . . .335 Declaration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Declaration set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Declaration subset . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Declarations within the document type declaration. . . . . . . . . . . . 28 Default. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .304 Default match. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182 Default values for parameters. . . . . . . . . . . . . . . . . . . . . . 37 Definition of terms. . . . . . . . . . . . . . . . . . . . . . . . 239, 304 Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Definitions for SGML constructs. . . . . . . . . . . . . . . . . . . . . 19 Definitions for terms created for or used by this specificatio . . . . . 21 Description Column . . . . . . . . . . . . . . . . . . . . . . . . .73, 161 Design goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171 Disposition of Document Type Declarations. . . . . . . . . . . . . . . . .2 Document structure . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Document type declaration. . . . . . . . . . . . . . . . . . . . . . 20, 28 Document type declaration example. . . . . . . . . . . . . . . . . . . . 27 Document type declaration set. . . . . . . . . . . . . . . . . . . . . . 21 Document type declaration subset . . . . . . . . . . . . . . . . . . . . 22 Document type declarations . . . . . . . . . . . . . . . . . . . . . . . 46 Document Type Definition (DTD) . . . . . . . . . . . . . . . . . . .20, 304 DTD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Electronic review. . . . . . . . . . . . . . . . . . . . . . . . . .14, 388 Electronic review comments . . . . . . . . . . . . . . . . . . . . .15, 388 Electronic review declaration set. . . . . . . . . . . . . . . . . .15, 388 Electronic Review Declaration Set Overview . . . . . . . . . . . . . . .388 Electronic Review Declaration Set. . . . . . . . . . . . . . . . . . . .389 Electronic Review Functionality. . . . . . . . . . . . . . . . . . . . .391 Electronic Review Process. . . . . . . . . . . . . . . . . . . . . . . .392 Electronic review process improvement. . . . . . . . . . . . . . . .14, 388 Electronic Review User Interface . . . . . . . . . . . . . . . . . . . .392 Element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Element and attribute set descriptions . . . . . . . . . . . . . . . . . 73 Element type declaration . . . . . . . . . . . . . . . . . . . . . . 21, 30 Element type set . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Element Type/Attribute Column. . . . . . . . . . . . . . . . . . . . . . 73 Element, in-context. . . . . . . . . . . . . . . . . . . . . . . . . . .305 Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Entity declaration . . . . . . . . . . . . . . . . . . . . . . . . . 21, 29 Entity reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Entity set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Enumeration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 225, 305 Equivalency definitions. . . . . . . . . . . . . . . . . . . . . . . . .304 Evaluating a fillval . . . . . . . . . . . . . . . . . . . . . . . . . .187 EXAMPLE DOCTYPE FOR TECHNICAL DOCUMENTS. . . . . . . . . . . . . . . . . 47 External entities. . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 FILLVAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186 Fillval syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187 Finite list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 Float. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 Floating area characteristics. . . . . . . . . . . . . . . . . . . . . .266 Floating constructs. . . . . . . . . . . . . . . . . . . . . . . . . . .192 Floating locations . . . . . . . . . . . . . . . . . . . . . . . . . . .199 Flowing text area. . . . . . . . . . . . . . . . . . . . . . . . . . . .259 Flowing text area characteristics. . . . . . . . . . . . . . . . . . . .265 Font . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201, 305 Footer area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259 Footnote area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260 Footnote description (ftndesc) . . . . . . . . . . . . . . . . . . . . .175 Footnote placement . . . . . . . . . . . . . . . . . . . . . . . . . . .267 Formatting Output Specification Instance (FOSI). . . . . . . . . . .22, 305 Full-Name Column . . . . . . . . . . . . . . . . . . . . . . . . . .73, 161 General application. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Generic identifier (gi). . . . . . . . . . . . . . . . . . . . . . . . .305 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19, 304 Government documents . . . . . . . . . . . . . . . . . . . . . . . . 3, 173 Government specifications and standards. . . . . . . . . . . . . . . 3, 173 Graphic characteristics. . . . . . . . . . . . . . . . . . . . . . . . .240 Graphic placement. . . . . . . . . . . . . . . . . . . . . . . . . . . .305 Graphic sizing . . . . . . . . . . . . . . . . . . . . . . . . . . 240, 305 Graphics and other non-SGML data entities. . . . . . . . . . . . . . . . 37 Graphics description (grphdesc). . . . . . . . . . . . . . . . . . . . .175 GUIDELINES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .286 Guidelines for document type declaration creation. . . . . . . . . . . . 38 Gutter area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260 Hardcopy and softcopy application. . . . . . . . . . . . . . . . . . . . .9 Header and footer. . . . . . . . . . . . . . . . . . . . . . . . . . . .263 Header area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .258 Highlight. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206, 305 Hyphenation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 202, 305 Hyphenation rules. . . . . . . . . . . . . . . . . . . . . . . . . . . .194 Hyphenation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 ID and IDREF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 Identification and treatment of source data. . . . . . . . . . . . . . .287 Identification of Document Type Declaration Sets . . . . . . . . . . . . 13 Identifier (ID). . . . . . . . . . . . . . . . . . . . . . . . . . . . .305 Identifier reference (IDREF) . . . . . . . . . . . . . . . . . . . . . .305 Illustration files . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Implementation notes . . . . . . . . . . . . . . . . . . . . . . . . . .183 Inclusion of standard text . . . . . . . . . . . . . . . . . . . . . . . 40 Indent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .305 Inheritance. . . . . . . . . . . . . . . . . . . . . . . . . . . . 254, 305 Inheritance and defaulting . . . . . . . . . . . . . . . . . . . . . . .187 Integer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 Integrity, page. . . . . . . . . . . . . . . . . . . . . . . . . . . . .306 Intended use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Intent of a FOSI . . . . . . . . . . . . . . . . . . . . . . . . . . . .287 Interaction of the reproduction window, sizing, and placement. . . . . .239 Interim and partial document delivery requirements . . . . . . . . . . . .4 Interim deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . 15 INTRODUCTION . . . . . . . . . . . . . . . . . . . . 26, 170, 175, 286, 309 IS0 8879 - general concepts. . . . . . . . . . . . . . . . . . . . . . . 26 ISO 8879 - background. . . . . . . . . . . . . . . . . . . . . . . . . . 26 Justification, vertical. . . . . . . . . . . . . . . . . . . . . . . . .306 Keeps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306 KEY TO CHARACTERISTICS . . . . . . . . . . . . . . . . . . . . . . . . .194 Layout areas . . . . . . . . . . . . . . . . . . . . . . . . .177, 254, 306 Leading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201, 306 Left margin area . . . . . . . . . . . . . . . . . . . . . . . . . . . .257 Letterspace. . . . . . . . . . . . . . . . . . . . . . . . . . . . 203, 306 List, finite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306 Machine processability . . . . . . . . . . . . . . . . . . . . . . . . .171 Margin, bind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306 Margins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263 MATH DECLARATION SET . . . . . . . . . . . . . . . . . . . . . . . . . .379 Mathematical Element Type Descriptions . . . . . . . . . . . . . . . . . 73 Media. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170 Methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .298 MIL-M-38784 application. . . . . . . . . . . . . . . . . . . . . . . . . 10 Model group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Modularization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Multiple fillval and specval specifications. . . . . . . . . . . . . . .187 Multiple page models . . . . . . . . . . . . . . . . . . . . . . . . . .254 Non-Government publications. . . . . . . . . . . . . . . . . . . . . 3, 173 Notation declaration . . . . . . . . . . . . . . . . . . . . . . . . . . 28 NOTES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306 Order of precedence. . . . . . . . . . . . . . . . . . . . . . . . . . .174 Order of processing. . . . . . . . . . . . . . . . . . . . . . . . . . .190 Organization of this appendix. . . . . . . . . . . . . . . . . . . . . .171 Ormatting Output Specification Instance (FOSI) . . . . . . . . . . . . . 11 OS and FOSI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Output file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Output file delivery . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Output file delivery requirements. . . . . . . . . . . . . . . . . . . . .4 Output files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 OUTPUT SPECIFICATION . . . . . . . . . . . . . . . . . . . . . . . . . .170 Output Specification (OS). . . . . . . . . . . . . . . . . . . . . .22, 306 OUTPUT SPECIFICATION (OS) CONCEPTS . . . . . . . . . . . . . . . . . . .175 OUTPUT SPECIFICATION DTD . . . . . . . . . . . . . . . . . . . . . . . .269 Overview of graphics functionality . . . . . . . . . . . . . . . . . . .298 PACKAGING. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Packaging requirements . . . . . . . . . . . . . . . . . . . . . . . . . .7 Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .261 Page area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257 Page description (pagedesc). . . . . . . . . . . . . . . . . . . . . . .175 Page description languages . . . . . . . . . . . . . . . . . . . . . . . 11 Page fidelity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Page integrity . . . . . . . . . . . . . . . . . . . . . . . . . .5, 13, 22 Page integrity and page fidelity . . . . . . . . . . . . . . . . . . . .171 Page model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306 Page models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254 Page models and layout characteristics . . . . . . . . . . . . . . . . .253 Page set . . . . . . . . . . . . . . . . . . . . . . . . . . .255, 261, 306 Pagination characteristics . . . . . . . . . . . . . . . . . . . . 176, 261 Parametrization of modules . . . . . . . . . . . . . . . . . . . . . . . 37 Parseability, machine. . . . . . . . . . . . . . . . . . . . . . . . . .306 Partial document delivery. . . . . . . . . . . . . . . . . . . . . . . . 15 Placement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242 Point. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306 Pointer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178, 306 Positioning techniques . . . . . . . . . . . . . . . . . . . . . . . . .289 Postspace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210, 307 Preparation of document type declaration sets. . . . . . . . . . . . . . 12 Prespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209, 307 Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183, 307 Processing instructions. . . . . . . . . . . . . . . . . . . . . . . . . 14 Processing system considerations . . . . . . . . . . . . . . . . . . . . 13 Pseudo-element . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307 Pseudo-elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . .187 PUBLIC TABLE DEFINITIONS . . . . . . . . . . . . . . . . . . . . . . . .350 Publication management and processing considerations . . . . . . . . . . 12 Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Putgraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226 Puttext. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226, 307 Quadding, horizontal . . . . . . . . . . . . . . . . . . . . . . . . . .307 Quadding, vertical . . . . . . . . . . . . . . . . . . . . . . . . . . .307 QUALITY ASSURANCE PROVISIONS . . . . . . . . . . . . . . . . . . . . . . .6 Quality assurance requirements . . . . . . . . . . . . . . . . . . . . . .6 Reading a document type declaration. . . . . . . . . . . . . . . . . . . 26 REPLACEMENT TEXT ENTITY DECLARATIONS . . . . . . . . . . . . . . . . . .336 Reproduction area dimensions . . . . . . . . . . . . . . . . . . . 240, 307 REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Reset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223 Resource description (rsrcdesc). . . . . . . . . . . . . . . . . . . . .175 Resource description characteristics . . . . . . . . . . . . . . . . . .194 Responsibility for compliance. . . . . . . . . . . . . . . . . . . . . . .6 Responsibility for inspection. . . . . . . . . . . . . . . . . . . . . . .6 Right margin area. . . . . . . . . . . . . . . . . . . . . . . . . . . .258 Ruling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224, 307 Savetext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228, 307 Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . .1, 24, 170, 309 Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192 Security description (secdesc) . . . . . . . . . . . . . . . . . . . . .175 SGML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 SGML declaration . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 43 SGML document type declaration sets. . . . . . . . . . . . . . . . . . . 11 SGML DOCUMENT TYPE DECLARATIONS. . . . . . . . . . . . . . . . . . . . . 46 SGML entity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Shorthand. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Size/distance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 Source file configuration control. . . . . . . . . . . . . . . . . . . . 14 Source file delivery . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Source file delivery requirements. . . . . . . . . . . . . . . . . . . . .4 Sources of graphics information. . . . . . . . . . . . . . . . . . . . .239 Span . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216, 307 Special features . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Specification revisions. . . . . . . . . . . . . . . . . . . . . . . . . 11 Specifications covered . . . . . . . . . . . . . . . . . . . . . . . . . .2 Specifying elements-in-context (e-i-c) . . . . . . . . . . . . . . . . .178 Spell checking and hyphenation . . . . . . . . . . . . . . . . . . . . . 14 Spell checking.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Standard text conventions. . . . . . . . . . . . . . . . . . . . . . . . 40 Start- and end-tag minimization. . . . . . . . . . . . . . . . . . . . . 33 Statement of purpose, premises . . . . . . . . . . . . . . . . . . . . .170 Step 1 - Understanding the requirements. . . . . . . . . . . . . . . . .286 Step 10 - Determining element categories . . . . . . . . . . . . . . . .291 Step 11 - Describing elements. . . . . . . . . . . . . . . . . . . . . .291 Step 12 - Handling source attributes . . . . . . . . . . . . . . . . . .297 Step 13 - Describing graphics. . . . . . . . . . . . . . . . . . . . . .298 Step 14 - Describing tables. . . . . . . . . . . . . . . . . . . . . . .299 Step 15 - Describing footnotes . . . . . . . . . . . . . . . . . . . . .300 Step 16 - Verifying the FOSI . . . . . . . . . . . . . . . . . . . . . .303 Step 2 - Understanding OS concepts . . . . . . . . . . . . . . . . . . .287 Step 3 - Organizing and documenting a FOSI . . . . . . . . . . . . . . .287 Step 4 - Setting up the resource description . . . . . . . . . . . . . .288 Step 5 - Setting up the security description . . . . . . . . . . . . . .288 Step 6 - Setting up page models. . . . . . . . . . . . . . . . . . . . .288 Step 7 - Setting up the style description. . . . . . . . . . . . . . . .291 Step 8 - Setting up the document default . . . . . . . . . . . . . . . .291 Step 9 - Setting up environments . . . . . . . . . . . . . . . . . . . .291 String . . . . . . . . . . . . . . . . . . . . . . . . . . . .178, 198, 307 Style description (styldesc) . . . . . . . . . . . . . . . . . . . . . .175 Subject term (key word) listing. . . . . . . . . . . . . . . . . . . . . 22 Support file delivery. . . . . . . . . . . . . . . . . . . . . . . . . . .9 Support file delivery requirements . . . . . . . . . . . . . . . . . . . .4 Suppress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221 Table Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Table description (tabdesc). . . . . . . . . . . . . . . . . . . . . . .175 Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Technical publication data requirements. . . . . . . . . . . . . . . . . 18 Technical publication management considerations. . . . . . . . . . . . . 12 Technical publication verification . . . . . . . . . . . . . . . . . . . 22 Technique - Controlling floating elements. . . . . . . . . . . . . . . .290 Technique - Controlling hyphenation. . . . . . . . . . . . . . . . . . .293 Technique - Determining the font . . . . . . . . . . . . . . . . . . . .292 Technique - Documenting a FOSI . . . . . . . . . . . . . . . . . . . . .288 Technique - Grouping elements. . . . . . . . . . . . . . . . . . . . . .291 Technique - Identifying source attributes. . . . . . . . . . . . . . . .297 Technique - Interaction of attributes and other values . . . . . . . . .298 Technique - Interaction of Puttext, Putgraph, and Usetext. . . . . . . .297 Technique - Order of elements-in-context in the FOSI . . . . . . . . . .287 Technique - Saving text for multiple uses (Savetext) . . . . . . . . . .296 Technique - Setting page parameters. . . . . . . . . . . . . . . . . . .289 Technique - Setting up footnote areas. . . . . . . . . . . . . . . . . .290 Technique - Setting up headers and footers . . . . . . . . . . . . . . .289 Technique - Specifying change marks. . . . . . . . . . . . . . . . . . .294 Technique - Specifying keeps . . . . . . . . . . . . . . . . . . . . . .294 Technique - Specifying leadin. . . . . . . . . . . . . . . . . . . . . .293 Technique - Specifying prespace and postspace. . . . . . . . . . . . . .294 Technique - Specifying quadding. . . . . . . . . . . . . . . . . . . . .293 Technique - Specifying text breaks . . . . . . . . . . . . . . . . . . .294 Technique - Specifying the use of the attribute. . . . . . . . . . . . .297 Technique - Specifying vertical justification parameters . . . . . . . .294 Technique - Specifying word spacing, letter spacing, and kerni . . . . .293 Technique - Suppressing text . . . . . . . . . . . . . . . . . . . . . .295 Technique - Using automatic numbering. . . . . . . . . . . . . . . . . .295 Technique - Using borders. . . . . . . . . . . . . . . . . . . . . . . .295 Technique - Using character fills. . . . . . . . . . . . . . . . . . . .295 Technique - Using context and occurrence . . . . . . . . . . . . . . . .291 Technique - Using generated text (Puttext) . . . . . . . . . . . . . . .296 Technique - Using highlighting . . . . . . . . . . . . . . . . . . . . .293 Technique - Using indents. . . . . . . . . . . . . . . . . . . . . . . .293 Technique - Using inheritance and defaulting . . . . . . . . . . . . . .292 Technique - Using page references. . . . . . . . . . . . . . . . . . . .289 Technique - Using page sets. . . . . . . . . . . . . . . . . . . . . . .288 Technique - Using pre-defined graphics (Putgraph). . . . . . . . . . . .296 Technique - Using rules. . . . . . . . . . . . . . . . . . . . . . . . .295 Technique - Using saved text (Usetext) . . . . . . . . . . . . . . . . .297 Technique - Using spans. . . . . . . . . . . . . . . . . . . . . . . . .295 Technique - Using string . . . . . . . . . . . . . . . . . . . . . . . .297 Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180 Text Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241 Text flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254 Text markup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Text types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Textbreak. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214, 307 Toggle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178, 307 Top margin area. . . . . . . . . . . . . . . . . . . . . . . . . . . . .257 Transmittal Master . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Unfielded data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Use of document type declaration sets. . . . . . . . . . . . . . . . . . 13 Use of inclusion and exclusion exceptions. . . . . . . . . . . . . . . . 33 Uses of entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Usetext. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233, 307 Using graphics and other non-SGML data . . . . . . . . . . . . . . . . . 42 Using page numbers . . . . . . . . . . . . . . . . . . . . . . . . . . .290 Using special characters . . . . . . . . . . . . . . . . . . . . . . . . 41 Using the Electronic Review Toolkit. . . . . . . . . . . . . . . . . . .390 Value types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 Vertical justification . . . . . . . . . . . . . . . . . . . . . . . . .213 Wildcard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307 Wordspace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202, 307 World coordinates. . . . . . . . . . . . . . . . . . . . . . . . . . . .240 CONCLUDING MATERIAL Custodians: Preparing Activity Army - CR OASD (P&L) - DO Navy - SH (Project IPSC-0266) Air Force - 16 DLA - DH Review Activities: Army - AL, AR, AV, ER, MR, MI, AT, TE, ME, GL, TM, SM, SC, CU, AC Air Force - 01, 02 NSA - NS DCA - DC NASA - NA Other - DOE, NCS User Activities: OASD - IR Navy - AS, EC, OS, SA, YD Air Force - 11, 13, 17, 18, 19, 68, 79, 99 DLA - IS, CS, GS, ES