The 24 modules can be classified into the following categories:
Categories of DTD modules, corresponding to types of information
DTD modules for descriptive information types
The descriptive information is built up of sections (avsnitt) containing a title and ordinary text components. Sections can be placed inside each other, and are thereby regarded as subsections in a hierarchical fashion. There is no limit on how many subsections one can have, but if the breakdown of the materiel system is fairly thorough, there should rarely be need for more than two or three levels.
DTD modules for procedural information types
Procedural information is basically built up of the procedure itself, and its preconditions and postconditions. The basic idea with a procedure is that it gives information on what needs to be done. How it is to be done is described elsewhere (e.g. in a uh.atgard, maintenance task), or maybe as a procedure on a lower level (only if this is the only use of that procedure).
The quite large number of modules for procedural information stems from the fact that the top structure differs somewhat. The only exception to this is renovering and modifiering, which have identical structures but are to their nature different types of information, so the design group therefore decided to use two modules.
DTD modules for "data" information types
The data type modules can be regarded as mirrors of databases. In the absence of one, general database solution for all information of this type, those modules have been created to enable retrieval and re-use of information that might or might not be stored in a database.
If a real database, containing this type of information (no less), is available to the presentation system, all links to these modules may be redirected into the database and the true source information directly.
Note: This may pose legal problems in some cases, since databases do not use version control in the same sense as documentation.
DTD modules for assembled information
The common denominator for those modules is that the illustration and the text has a "cross reference" in the call-out system, which is specific to each illustration (or materiel system). Those information modules tend to be publication specific, but the combination of an illustration and text is very valuable to end users, and there is no other way of structuring this information at this detailed level.
The idea is that for a delivery, one module of the type admindata is assembled, containing information on all other information modules in the delivery. In a storage environment, as well as during production and in a presentation application, this type of information is supposed to be handled by an administrative system, and there might not be any need of keeping an admindata module at that time.
The structure of the admindata module is heavily based on similar structures in FMV Base DTD, and earlier version of the Grund-DTD used e.g. in the FVSDUP project. The FVSDUP project was the only project available at FMV in which information of this type could be found. When other projects employs digital delivery, we suspect changes to this module to be required.
This enables us to place all linking information externally from the information modules, in a separate module, lankar. For managerial reasons we believe that only one, or at least very few modules of this type will be used in a system. It might even be efficient to handle the linking information in a database system or document management system, and create the linking module at delivery.
Except from the HyTime linking constructs, this module (or rather its declaration subset) must also contain entity references to all information modules, graphics, and other "fragments".
Note: The method of HyTime linking is further described below.
Given the information product module, and the information modules it assembles, a presentation format can be applied and, possibly after some specific processing to re-organise the information slightly, a document can be obtained.
The infoproduktmodul is to its nature very different to the information modules described by the DTD. Its sole purpose is to organise other information modules in some hierarchical fashion, for a specific purpose, e.g. paper document, DynaText book, etc.
Information product modules may also point at other information product modules. Thereby hierarchical structures of information product modules may be set up, e.g. to organise chapters of a book separately.
If a logistic support analysis (LSA) has been conducted, the breakdown is probably quite detailed, but smaller systems may not have a defined breakdown structure at all.
Note: It is important that also the operational tasks are covered by the LSA, in order to supply a structure (or objects) for technical information purposes.
And even given a detailed breakdown structure, what's the decision for using information fragments for version and variant control? What's the best level of "smallest information chunk" for the defence? And what's the best level for each of the other parties in the deal?
The decision is probably specific for each project, but some guidance may be given.
Technical information that is going to be integrated with other information during its lifetime, in a product model or otherwise, must be broken down. Preferably this is done in a standardised way, e.g. through an LSA. The breakdown must be fairly detailed, if the integration of information shall have high functionality, probably down to LRU. The information modules for such a system will be very small, and this is the concept of information modules for which the DTD has been tailored.
Technical information that will be updated frequently in the future will gain of using information fragments for version and variant control. Most information need to be updated frequently, but the cost of updates makes it often impossible to update. Some materiel systems documentation has never been updated, and the documentation is totally wrong today. One must be conscious of that the production cost of using information fragments is much higher (at least today), since it requires advanced systems to handle the information, but that cost must be balanced against the cost of updates.
Tables in FMV Grund-DTD are basically built of rows, which contains cells. Through the use of table blocks, a number of rows can be grouped together. Tables may have a column head, which consists of rows with cells.
A cell may contain text, notes anm, figures bild and verbatim text tecken.for.tecken. Verbatim text means that all line breaks and tabs are preserved, and it could therefore be used where line breaks and spaces are significant. The verbatim text is however only available in table cells.
The intention is that for a certain type of information, there is a relatively small number of table formats that can be predefined and named. The name of such a table is entered as value in this attribute.
The recommended values are built up in several parts, according to the following syntax:
2 columns 3 columns 4 columns 5 columns 2kol.1.1 3kol.1.1.1 4kol.1.1.1.1 5kol.1.1.1.1.1 2kol.1.2 3kol.1.1.2 4kol.1.2.2.2 5kol.1.2.2.2.2 2kol.1.4 3kol.1.1.4 4kol.1.2.1.2 5kol.1.2.3.3.3 2kol.1.8 3kol.1.1.7 4kol.1.4.1.4 5kol.1.4.2.2.2 2kol.2.1 3kol.1.2.1 4kol.1.2.3.4 5kol.3.1.1.1.1 2kol.4.1 3kol.1.2.2 4kol.1.5.2.2 5kol.6.1.1.1.1 3kol.1.2.4 4kol.2.1.2.3 3kol.1.4.4 4kol.2.1.1.1 3kol.2.1.1 4kol.7.1.1.1 3kol.2.1.3 3kol.4.4.1 6 columns 7 columns 8 columns 6kol.1.1.1.1.1.1 7kol.1.1.1.1.1.1.1 8kol.1.1.1.1.1.1.1.1 6kol.1.2.2.2.2.2 7kol.5.1.1.1.1.1.1 8kol.5.1.1.1.1.1.1.1 6kol.1.4.2.2.2.2 6kol.3.1.1.1.1.1 6kol.5.1.1.1.1.1 6kol.3.2.2.1.1.1
Let's take an example:
Table 1: Computer speed benchmark Computer name CPU index Disk index IBM XT 4.77MHz 1.0 1.0 (10MB) IBM AT 8MHz 4.4 2.1 (30MB) Compaq 386s/16MHz 9.1 6.4 (40MB) Compaq 386/20e 20MHz 20.5 6.4 (110MB) Compaq 486/25MHz 53.6 10.3 (300MB)The information in a single cell is useless if its context is unknown, i.e. given the figure "53.6" without knowing that it's the CPU index for a Compaq 486/25MHz.
In this example, the table element start tag would look like this:
<tabell id='t1' titel='Computer speed benchmark' sammanhang.spec='col1.content this.col.head' tabklass='egbert'>And the cell:
<cell id='c6' sammanhang='"Compaq 486/25MHz" "CPU index"'> 53.6 </cell>From this it would be possible to extract the single cell, process the information, and present it as:
The Compaq 486/25MHz CPU index is 53.6.
or maybe:
CPU index 53.6 belongs to Compaq 486/25MHz.
It is not possible to group non-contiguous elements with the DTD, i.e. all elements in between the first and last element of the block are a part of the block.
Blocks in procedural information, moment.block, sekv.block, and sekv.block.sub, must be used to enter warnings and cautions, varn and obs, inside a procedure. The warning must belong to some actions, steps, and the block indicates where the warning is valid (a warning at the beginning is valid throughout the entire procedure).
Example of a block in procedural information
The tabell.block is a little bit special, since it can be used to group table rows. This function could be used to label rows, i.e. some sort of row headers can be obtained by using table blocks and their titles.
Example of table blocks
HyTime consists of six modules that may be used in an application:
The use of HyTime and its modules are declared in HyTime declarations (see the end of file FMVGRUND.DCL). In every HyTime "document", i.e. all modules containing HyTime syntax, the HyTime declarations must be present to initiate HyTime processing.
HyTime defines a number of architectural forms, that can be used in SGML DTD's such as FMV Grund-DTD. HyTime does not define elements, but by declaring elements in your DTD as being conformant to a HyTime architectural form, it is possible to initiate HyTime processing on that element. An architectural form could be described as a meta-element.
Note: Neither SGML nor HyTime defines any aspects of presentation. The presentation is defined by the application that process and presents the SGML encoded information, and what might be suggested or implied by the codes can be overridden.
A simplified illustration of a HyTime independent link
The link in the example above consists of the following elements (or architectural forms):
A nameloc may contain several nmlists, and a nmlist may point at another nameloc. In this way, very complicated and hierarchical links may be created.
There are four types of links in FMV Grund-DTD, all built on the architectural forms described above.
The information that is referenced, the target information, does not belong to the module, but complements it.
In a paper presentation, the target information is not printed at the place of the reference. Instead, the reference is presented as e.g. "see section 4.2" or "see further 'Safety regulations for welding', TO1234-56".
In a computer based application, the user must interact with the application to see the target information, e.g. by clicking on a button or "hot spot".
In FMV Grund-DTD there is one link element of this type: lnk.hanv. It is used for all types of references in the following ways.
References to other modules
References to foreign SGML documents
References to inaccessable documents
References into other modules
References to interval (span)
The target information may consists of small pieces of information, "data", which would be the case when including data from databases. It can also be one element, or entire element structures (e.g. a section), which would be the case for standard warnings, general text paragraphs, and also when versions and variants of information modules are handled through HyTime linking.
In a paper presentation, the target information is printed at the place of inclusion. The included information is an integrated part of the information module, and without it the information would not be complete.
In a computer based application, the target information is likewise automatically included and presented to the user, without requiring him to interact at all. In fact, it should be impossible for an end user to see the information without its inclusions.
In FMV Grund-DTD there are two links of the type inclusion:
Ilink element Description
Links for inclusion of fragments
Links for Inciusion of data
Note: The current release of FMV Grund-DTD treats graphics, video and audio as one entity, it is not possible to link into any of these, or to e.g. control a video sequence. To do this, other modules of HyTime are required.
This link takes a position in-between references and inclusions, or belong to both, since this type of information can be both referenced and included depending on the author's intentions.
Whether the link is to be treated as a reference or as an inclusion is decided by the application and the project, based on the values of one of the link's attributes, the viktighet (importance) attribute. As a rule of thumb the following recommendation can be used: if viktighet is set to nodvandig (essential) or viktig (important) the link is treated as an inclusion, and if it is bakgrundsinfo (background information) it is treated as a reference. However, it is up to the application and the project to decide, and the decision may be different for different types of information modules.
In FMV Grund-DTD there is one link of the type non-SGML, and the ilink element is named lnk.nonsgml.
A link to non-SGML data
This link type requires that each information module has its own nameloc element that represents it. The nameloc element is of course stored in the linking module lankar, within the adr.modul element, and it might be a good idea to create that element at the same time as the module is created. The nameloc element is important for the information module, since it carries information regarding versioning and possible variants.
Belonging links must be used by an application, if any structure or administrative information regarding modules and their connection to objects should be presented. There is no information inside an information module that indicates to what object it belongs (i.e. not in the SGML codes), that information is placed entirely in this link. Likewise, all administrative information is placed in the link or in the admindata module.
In FMV Grund-DTD there are two links of the type belonging.
Ilink element Description
Since one object will have a number of information modules connected to it, and an information module in turn may be connected to several objects, the addressing in the lnk.objekt link is slightly more complicated than in other links, there is one more step of indirection here.
Link between module and object
The lnk.admin is the connection between an information module and its administrative data, and therefore it may only connect one module to one element of the type moduladmin in the module admindata. All modules (except admindata) must have this type of link.
Link between Info module and Admin data
However, there is a need for version and variant management for information modules, regardless of objects. This is taken care of by the HyTime links (or rather, by the nlok.modul and nlok.varianter elements in the linking module).
From a linguistic perspective it is difficult to define what is a version and what is a variant. In FMV Grund-DTD we have decided to regard version as a superset of variants, i.e. a version of an information module can have different variants.
Versions and variants of information modules
Detailed description of the DTD
Back to FMV Grund-DTD Table of Contents
FMV Grund-DTD version 1.10