FMV GRUND-DTD OVERVIEW

In this section, a technical overview of FMV Grund-DTD is given. It is divided in three conceptual parts:


Design and development principles

FMV Grund-DTD is built on the following basic design principles:

Information types in the DTD

FMV Grund-DTD is actually 24 different DTD's in one. We say it consists of 24 DTD-modules, one for each type of information that has been identified as necessary for operation and maintenance of materiel systems.

The 24 modules can be classified into the following categories:

Categories of DTD modules, corresponding to types of information

Descriptive information

The descriptive information modules are called: Furthermore, foreskrift (regulation) is a mix of descriptive and procedural 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.

Procedural information

There are a number of procedural information types, and some of them have attributes that further classifies them: Furthermore, foreskrift (regulation) is a mix of descriptive and procedural information.

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.

Data

The following DTD modules are of the type data:

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.

Assembled information

Information modules that consists of one or more illustrations that are described by textual data, often found in databases, are called assembled information. The following modules are of the type assembled information:

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.

Administrative information

The module admindata (administrative data) is used to supply administrative information regarding the other information modules, i.e. status, changes, responsible persons etc.

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.

Linking information

The linking module, lankar, is supposed to contain all links between information modules, and between modules and objects in a product model. All references, inclusions and other types of links are encoded with HyTime, ISO 10744, and are independent links, i.e. the linking information is separated from the actual points to be linked together.

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.

Information products

To be able to produce documents, publications, screen applications, etc. from a base of information modules, a means of putting them together in a specific hierarchy must be supplied. The module infoproduktmodul, information product module, defines the information used in an information product by pointing at the information modules.

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.


Deciding the level of granularity

Even if the DTD is created against what has previously been defined as an information module, the size or volume of an information module is dynamic. It depends on how far the materiel system has been broken down, i.e. system, sub-system, assembly, sub-assembly, component, line replaceable unit (LRU), etc.

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

Most traditional tables in defence documentation will be handled in another way than with the "table" code. Fault finding, technical data, spare part lists etc. are all handled with true content coding, without mentioning the presentation form "table". We could unfortunately not eliminate the need of "tables" entirely, so there is a specific table element, tabell. It is foremost used for simple tables, often without column headers.

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.

Table classes

There is no formatting at all in the table declarations. The only connection to formatting is a project definable attribute called tabklass.

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:

Recommended use: Use all, or a subset, of the following values:

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

Any extension to the recommended values here must be built on the same syntax, and must be reported to FMV.

Cell context

Each cell must carry information concerning the context of the information inside it, i.e. describe what the content of the cell is. This is done in attribute sammanhang. To support automatic generation of this attribute, the table element has an attribute called sammanhang.spec which specifies how the cell attributes are filled out.

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.


Blocking of information

The DTD contains a number of elements that are used to block, or group information: These elements are used to embrace elements that belong together in some way, e.g. text paragraphs and a figure, or a note and the text paragraph it belongs to. Blocks do not add another level of headings, it simply holds together information pieces.

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 and links

HyTime introduction

HyTime can be conceived as an extension to SGML. In FMV Grund-DTD, HyTime gives the possibility to create links between information modules, and to external objects, in a standardised way.

HyTime consists of six modules that may be used in an application:

In FMV Grund-DTD three of those are used: Base, location address and hyperlinks modules. Other modules of HyTime will probably be incorporated in future releases.

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 simple link

A link in HyTime consists of several elements, and works similar to pointers in a programming language. HyTime defines two types of links, or two types of architectural forms for links, independent link and contextual. The contextual link is placed at one of its anchors (an anchor is the point where a HyTime link ends). The independent links position is independent of its anchors. In FMV Grund-DTD we want to be able to manipulate the link without touching its anchors, so we use only the independent link, and further discussions regard only this type of link.

A simplified illustration of a HyTime independent link

The link in the example above consists of the following elements (or architectural forms):

A link can be traversed in both directions, even if one of them is the "pre-defined" direction.

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.

Links in FMV Grund-DTD

All relations in FMV Grund-DTD are encoded with HyTime, even references inside a single information module. All the HyTime elements (that constitutes the link itself) are stored in the linking module lankar, except for one type of link in the infoproduct module. No link information is placed in information modules, only the anchors in the form of id-attributes. By storing all link information separately, the links can be re-directed without modifying the information modules, which might be desirable for certain types of links.

There are four types of links in FMV Grund-DTD, all built on the architectural forms described above.

They are in turn divided in separate links, depending on the relations.

Reference link

A reference link is a link from one place to one or many other places. Any type of information can be referenced, a section, figure or table in the same module, another module or part of another module, a document or publication that is not part of the same materiel system, in digital form or on paper. If the linked target is in digital form and accessible by the application, the link may be resolved by the application. If it is not, the location of the target information (or other information about the target) may be presented instead. In such a case, the application must be able to deal with possible HyTime errors due to the fact that the link is not fully resolvable.

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)

Inclusion link

An inclusion link is used to include information into an information module. It is sometimes called an "active link" or a "live link". The information that is being included, the target information, is regarded as an integrated part of the information module and is always presented at the place of inclusion. It is however not stored there, not even at time of delivery in SGML format (delivery to a presentation system may manipulate the information as is best for the receiving system, as long as it won't be exported from that system). It is probably used in other information modules as well, and is by definition an information fragment.

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

lnk.inf.fragm
Inclusion of information fragments, i.e. an element (used together with the ihref conref attribute at the source anchor element)
lnk.inf.data
Inclusion of data

Links for inclusion of fragments

Links for Inciusion of data

Non-SGML link

A non-SGML link is used to reference and/or include information that is not coded with SGML, e.g. graphics, audio, video.

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

Belonging link

A link of the type "object belongings" describes the relation between information modules and objects or administrative data (meta-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

lnk.objekt
Connection between a module and an object (through its object representation element objekt)
lnk.admin
Connection between a module an its administrative data in module admindata
An object is assumed to have a unique id, possibly stored in a database somewhere. The element objekt is the interface to the outer world, and contains all information necessary for an application to establish a query or connection with other information connected to the object, e.g. product data or logistic data in a database.

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


Versions and variants

When a new version or variant of an object (e.g. a changed component or exchangable components) is created, it is assumed that the new version is given a new unique identifier. In FMV Grund-DTD this would be reflected as a new element of the type objekt. Thereby, information modules that are applicable for the new version must be linked to the new objekt element, and there is no further need to keep track of versions and variants of objects.

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.

Information module versions

In FMV Grund-DTD, the version of an information module depends on its production status. The version is controlled through the attribute modulstatus (on elements nlok.modul and nlok.varianter) which has five recommended values:

Information module variants

Variants of information modules may exist if e.g. the information is tailored towards different target groups, i.e. operator versus technician. There are four attributes which can be used to identify and separate information module variants (all on elements nlok.modul and nlok.varianter):

Each of these can be given project defined attribute values, and FMV Grund-DTD gives only examples of values to be used. It is the intention to establish recommended values for these in the future, if possible.

Versions and variants of information modules


Previous chapter

Detailed description of the DTD

Back to FMV Grund-DTD Table of Contents

FMV Grund-DTD version 1.10