If the DTDs are bound to support all the phases of an engineering process (), a new set of problems must be solved:
 
In most of the phases in the process not all information is available. This makes it nearly impossible to define the correct occurrence in the DTD. For the development of engine management software we found six different flavors of instances. Strictly speaking we need six different DTDs. The MSRSW.DTD has about 250 elements. Using SGML schema language it is impossible to manage this.
 
Sometimes parts of the data are created in different, even in parallel process steps. An example for this situation is the fact that the data dictionary of an engine management software is generated using some CASE tool while the prose description is captured by the engineer using an SGML/XML editor. This requires sophisticated version control strategies and process management.
 
In the intermediate steps in the process not all objects of the entire systems exist. This forces a method to handle broken links. For example when a function is defined, we know that someone else defines a variable which must be used. But this variable will be visible not before the integration phase. So the broken link is not a bug. It is a feature for the integration phase.
5.1. Natural addressing in MSR 4.2.2. Object oriented models For the final results in the process it is very helpful to go back to standard methods to establish links. This makes it easier to circulate the final results etc. for treatment with standard viewers. For this reason, MSR DTDs have an MSR specific method () of natural addressing in parallel to standard ID/IDREF, HyTime and XLL based methods. All the links will be synchronized for exchange using SGML tools (see also ).
 
Different tools use different global data models. This is reflected in the capabilities of the SGML generators in those tools, especially in terms of the available iterators. For example there may be an entire data dictionary knowing the function for each variable. On the other hand there may be a specific function knowing all its variables. So the same information is available but structured using different approaches.
In the first place it appears to make sense to have a sub-DTD for each process phase or even one per tool. This would allow to define the data set per process phase by this DTD. On the other hand, this approach requires specific SGML applications for each process phase. The knowledge about the data structures would also be process phase specific.
One DTD for different process phases
Figure 6:
For these reasons, we found it better to use same DTD for all the steps and information fragments instead of defining sub DTDs with different model roots. This makes sure that all applications can find all information using the same access path if the information is there. This makes application development and reuse of software much easier. This approach is the "clou" which makes the glue layer really universal. Some examples:
 
If there is a formatting engine producing paper documents for entire systems, it can also be used for instances in early process phases which are only filled partially. But the results of these intermediate steps can be presented without any further effort. Otherwise if a specific DTD is used, a specific application must be built.
 
If there is an import filter for an engineering tool which usually handles files in early phases, this filter can also be used with enriched instances created in latter stages.
 
If one of the writers is not capable to support the DTD in all details, the generated instances can be treated as Well Formed XML and upgraded to Valid XML using SGML/XML conversion tools.
Following this approach, there is only one DTD used in all process phases which supports a complete data model. This leads to the fact that in this DTD everything missed in one process phase should be optional. Practically speaking, any element must be optional. The DTD is still worthy because it defines a limited set of access paths to the data. The instances can still be handled as retrievable databases.