Coordinating SGML Projects to Maximize Corporate Benefits was the original title from this 1995 article. Although it hails from the past, its lessons for markup technologies, the management of standards, and the handling of corporate politics still ring true. It also showcases how common forces drove the emergence of practices that we now see in the Darwin Information Typing Architecture (DITA).

1. Coordinating SGML Projects to Maximize Corporate Benefits
CALS Expo International '95
Conference Proceedings [pp 247-253]
National Security Industrial Association
Long Beach, California – 1995
Joseph Gollner – Euclid Consulting Group
Ernest O'Dell – Department of National Defence CALS Office
Abstract
The Canadian Department of National Defence (DND) has made reducing the
cost of published information a major priority. The Department recognizes that a
sizable portion of potential savings will result from improved information quality and
usability. The challenge lies in ensuring that all areas of potential savings and quality
improvements are addressed and addressed in such a fashion that facilitates a
constructive synergy between modernization activities. DND is looking at a number of
technologies and management disciplines as tools for meeting these objectives.
Emphasis is being placed on object orientation in the design, development and
deployment of reusable Standard Generalized Markup Language (SGML) components
and the application of Configuration Management (CM) practices to these objects.
DND is currently designing an environment that will allow projects to share SGML
objects and continuously coordinate the implementation of new capabilities without
undermining the corporate benefits of an integrated approach.
1: Maximizing Corporate Benefits
The kind of the reductions and cost savings currently being demanded of DND
can only be realized through department-wide improvements in efficiency. This is
widely accepted. There is even a general management consensus that many of these
efficiencies will be the result of better resource sharing, with resources understood to
be any type of asset – data, infrastructure, personnel or systems. This environment has
been conducive to the growth of SGML in DND. SGML is seen as a mechanism for
improving the quality, timeliness and cost-effectiveness of documentation through the
use of standard document structures and corporately-shared systems for creating,
publishing and maintaining information.
Following the line of thinking that stresses the importance of sharing resources,
there are some who would conclude, erroneously, that the surest way to realize these
corporate benefits lies in establishing standards and mandating compliance. This is an
erroneous conclusion in part because it has been tried before and has failed. In fact, it has

2. been tried many times before and has always failed. The main reason why this is an
erroneous conclusion, and why attempts to base implementations on this conclusion have
always failed, stems from the fact that a single, static solution cannot successfully address
any problem where variability and change are significant factors. Unfortunately, variability
and change characterize most of the problems confronting large organizations like DND.
This is not to say there are no solutions, only that there are no easy or fixed solutions.
Let's translate this into the SGML domain. Say that it is one of our primary
objectives, and it is, to ensure that the many SGML projects ongoing within DND
ultimately result in a set of corporately-shared applications to facilitate the creation,
publication and maintenance of information. The development cost of these
applications would stabilize after their completion while the benefits associated with
their use would grow for as long as these applications remained operational. We might
find this so compelling a prospect that we establish a management infrastructure for
SGML initiatives that would ensure that all initiatives and Programs use these
applications, and the document structures that support them. Through various policy
instruments, we might even attempt to strip Programs of the ability to deviate from
the mandated standards and practices. To guard against the possibility that the
corporately-shared applications may not yet be perfect, we would establish a change
management process whereby modifications would be proposed by Programs or SGML
initiatives and approved by a suitable control board after an exhaustive analysis of the
impact on all corporately-shared applications. Having done all this, we would feel that
we had succeeded and had made a sizable contribution to the efficiency objectives of
our organization. We would be wrong.
What we would have in fact done is commit the logical error outlined above.
Our desire to establish corporately-shared SGML applications would have been valid.
Even our desire to promote uniformity among implementations to safeguard the
benefits of corporately-shared applications would have been essentially valid. Where
we made our error was in hoping, even believing, that once established the
corporately-shared applications would be basically sufficient to address unforeseen or
changing requirements. We also erred in thinking that a single, centrally-managed
process for change control could successfully handle the rising tide of change requests
that were driven, not by minor deficiencies in the corporately-shared applications, but
by new requirements from new Programs and new initiatives. This latter error was the
fatal one. What we should have done was make the change management environment
itself a corporately-shared application that was designed to ensure that all corporately-
shared applications would be adaptive to the variability of Program requirements and
the inevitability of change.

3. 2: SGML in DND
Within DND, SGML has been enjoying a steady rise in popularity. Many policy
documents, including the Information Management Directives that establish the role of
CALS (Continuous Acquisition and Lifecycle Support) within the Department, are
currently authored and published using SGML. These documents now find their way, in
electronic form, into every unit and organization within DND. In the domain of
technical information, the DND CALS Office has made significant progress in
developing, validating, implementing and modifying a Document Type Definition (DTD)
to describe and manage all operations and support information currently published for
DND equipment. With this expanding base of SGML-encoded information, the
opportunity presents itself to develop, and introduce into service, corporately-shared
applications designed to leverage the investment in SGML structures and improve
documentation quality and usability.
3: Departmental Initiatives and the Role of SGML
3.1: Automated Translation
Bilingualism is a reality in Canada and the cost of translation between the two
official languages is something DND must continually address. One area of ongoing effort
is automated translation whereby an application attempts to establish a sufficiently
accurate "understanding" of a text to be able to render a tolerable translation. This can
be sufficient for "ad hoc" translations (i.e. to quickly determine the general content of a
text) but, depending upon the clarity of the source text, there can remain
insurmountable ambiguities. Obviously, this is not acceptable for official documentation
which must always be available in both official languages. This applies, significantly, to all
technical documentation. In these cases where accuracy counts, automated translation
can be used to perform the initial translation with the intent that this will reduce the
amount of time and effort required by highly skilled translators to complete the
translation. It is for this reason that SGML DTDs within DND associate English and French
content as consecutive elements typically within a container element. High volume
automated translation applications will be able to "fill" one language element based on
the content of its twinned counterpart. This approach permits translators to view both
elements (English and French) simultaneously, saving on cross-referencing time, and
facilitate verification that everything that requires translation has been translated.
3.2: Simplified English
The language of composition for most documentation in DND is English and
therefore the typical translation process takes content from English and translates it into
French. As mentioned previously, ambiguities in the source text make translation

4. (automated and manual) more difficult and therefore more expensive and error-prone.
English is notoriously prone to ambiguities and it is generally conceded that reducing the
cost of translation from English will be a function of reducing the ambiguity of the English
source. This is, in part, the rationale for Simplified English (SE). SE also realizes benefits in
making the English text more readable for native English speakers. In effect, SE
establishes a constrained vocabulary and restricted syntax that are applied to the
content of official documentation. Different SE rules can be applied to different
document types (e.g. a Policy document versus a technical manual) and to different parts
of the same document (e.g. theory of operations versus a safety precaution). The link to
SGML is obvious in that SE rules can be invoked according to the appropriate document
type and element. For example, the SE rules may be very explicit about the vocabulary
and syntax of a maintenance step requiring that the sentence describing a step always
begin with an action verb (themselves selected from a restricted list of possible action
verbs). This type of quality control application would be directly dependent upon the
available SGML structures and element names (e.g. <Mainttask> <Step>).
3.3: Defence Terminology Management System
Implementations of SE must make specific exceptions for technical terminology
which obviously will not comply with the requirements of the constrained vocabulary.
The management of this terminology is the function of the Defence Terminology
Management System (DTMS). As with SE, the DTMS seeks to enforce a consistent
usage of terminology across the Department such that texts are unambiguous and
easily translated. SGML will be used to explicitly identify occurrences of terminology
(e.g. <term>) within the text and associate each occurrence of the term with the
appropriate acronym and definition, themselves defined within the text. The strategy
of the DTMS is to execute terminology control during the authoring process as
opposed to using a downstream review activity. Terms will be defined, delineated with
markup, and validated by authors with the support of intelligent applications that can
locate terminology occurrences and ensure that usage is consistent across the
document and reconciles with the departmental term database. The departmental
term database is itself conceived as a "live" database based upon document instances
that incorporate approved terminology. The population of this database from active
documents will rely very heavily on the use of the appropriate SGML elements.
3.4: Publishing Services
The most immediate, and probably most significant, cost savings to be realized
through a corporately-shared system will be in the publishing domain. Standardized
formatting instructions are being developed that will apply to SGML instances created

5. according to known (and managed) DTDs and implement departmental formatting
guidelines. There is also a requirement for shared publishing systems that will process
formatting instructions and instances for the production of all required output formats.
Finally, there is a need for a department-wide capability in high-volume on-demand
printing, and electronic dissemination and retrieval. DND has initiatives underway to
provide all of the above. The objective is to establish a robust and adaptable SGML
publishing capability within the department. Establishing this type of capability has
consequences for many SGML components and, in particular, those that are directly
processed by the publishing system and that must provide sufficient information to
allow formatting instructions to be applied successfully. Base text elements (e.g.
paragraphs), tables and graphics must all manifest a measure of standardization and
completeness for formatting purposes. Once in place, however, the benefits to be
realized through a corporately-shared publishing system are not only significant in
terms of cost but also in terms of reduced complexity. Programs can conceivably
reallocate resources to content preparation and the specific objectives of the Program
as opposed to engaging in expensive publication publishing projects.
3.5: Integrated Equipment Management Environment
It is understood that technical publications do not exist in a vacuum and that a
high proportion of the information typically bundled in a "technical manual" in fact
emerges from other sources. Behind the entire push toward electronic SGML-based
technical information is the desire to improve the currency of accessed information
(e.g. configuration status on the equipment being serviced), the level of reuse of
information created during established processes (e.g. logistics data) and the ability of
maintainers to execute actions when required in the context of a larger procedure (e.g.
ordering a replacement part). It comes as no surprise, then, that DND is proceeding
with efforts to establish an integrated environment for managing equipment
information. The following are a sample of initiatives underway to ensure that SGML-
encoded information fits neatly within a larger data management regime:
 Logistics Support Analysis Report (LSAR) / DND CALS DTD integration is being
prototyped to ensure that all information created during the Logistic Support
Analysis (LSA) process that will be reused within published technical information
has corresponding destination elements in SGML document structures;
 Equipment Program Management Information System is an initiative, under the
Operation Excelerate re-engineering project for the Materiel Group, that will
establish an integrated working environment for the management of equipment

6. information with the consequent impact upon all information extracted from
this environment and published in SGML;
 Material Support Data Model (MSDM) is a conceptual data model being
prepared for the information requirements of materiel support. Data definitions
established here will have a broad influence on all applications, including SGML-
based applications (e.g. DND CALS DTD), within the Materiel Group;
 Management of Government Information Holdings (MGIH) is a government-
wide policy directing the manner in which departments, such as DND, manage
their information holdings. This impacts the way identification and management
information is described by departmental DTDs and implemented in the
resulting SGML instances.
4: Design, development and maintenance of shared SGML objects
The variety of initiatives within DND, each impacting upon different aspects of
SGML implementation, forces us to consider the issue of establishing, enforcing and
managing corporately-shared systems and standards. There are obvious potential
benefits offered by quality improvements, reduced processing costs (e.g. publishing
and translation) and better integration between published information and the
management processes for that information. However, it is also immediately apparent
that the complexities of implementing the required corporately-shared applications,
and coordinating the impact upon in-service SGML components, poses serious risks to
ever realizing these benefits. Having overcome these risks, the temptation will be great
to force closure on SGML component development and modification as soon as these
corporately-shared applications have been successfully implemented. As we have seen
before, surrendering to this temptation would be a mistake. How then will we bring
into service corporately-shared applications for translation, Simplified English,
terminology management, publishing and information management, bearing the
separate costs of each implementation, and ensure that new or changing requirements
can be accommodated without incurring an unacceptable cost in modifying each
application to suit each deviation? The answer lies in the way we design, develop and
maintain SGML objects.
4.1: Object-Orientation
To date, we have designed SGML DTDs, and associated components (e.g. output
specifications), strictly on an application by application basis. As soon as we must
simultaneously address the requirements of existing corporately-shared applications in

7. addition to the specific application being considered, then, as DTD designers, we are
constrained in the way we address certain functionality. What is important to
determine is where, and in what manner, we are constrained if we plan to produce an
SGML application that can also exploit the corporately-shared support applications.
Once this has been determined, we can assess what functional trade-offs may be
necessary due to conflicts between corporate and local requirements. To arrive at this
point, we must be able to access SGML sub-components, or objects, that provide the
building blocks for incorporating corporately-shared functionality into new SGML
constructs. Following this process also has a general impact in that our DTD will be a
modular construct rather than being a single, self-defining entity.
In this context, SGML objects are understood to be coherently defined groups of
inter-dependent SGML components. On the first level, an SGML object is comprised of
a logically integral DTD fragment together with the directly associated processing
instructions or requirements (e.g. formatting specification instances) for all
applications (corporate and local) to process information complying with the DTD
fragment. On a second level of detail, an SGML object contains all the information
required to understand and manage the functionality provided, or supported, by the
object. The SGML object includes all documentation for elements/attributes of the DTD
fragment, their associated processing requirements, the associated application
functionality, the user community and usage scenarios, current implementations, test
and demonstration instances, and management information about the object.
Management information would include identification, domain, version, revision,
Office of Primary Interest (OPI) or sponsor, Offices of Collateral Interest (OCI) or
stakeholders, creation and revision dates, and registration status (e.g. in development
or approved for use). By taking this approach we have effectively created "functional
objects" that encapsulate the data definitions (DTD fragment) together with the
associated methods (functionality). What we have, as a result, are meaningful SGML
building blocks that make it as straightforward as possible for DTD developers to
identify and understand functionality that is currently provided by corporately-shared
applications.
Recalling the corporate applications being developed within DND, we can begin
to see how this approach would operate in practice. Support for automated translation,
Simplified English validation, terminology management, publishing services and
information management guidelines has a direct impact upon the SGML object that
defines base text elements as well as common structures such as tables. In establishing
this logical grouping as an SGML object, the close link between the SGML structures
and the associated functionality is made explicit. Changes to base text elements can
potentially have dramatic implications for the associated functionality. Support for
Simplified English validation and information management guidelines (in particular,
data integration) depends on aspects of content specific deployments of SGML (e.g.

8. <Maint-task>). In the case of supporting the requirements of departmental information
management guidelines (MGIH), there is a very specific association of content elements
(e.g. <subject>) with desired functionality (e.g. archival storage and retrieval).
4.2: Configuration Management
Once we have created a set of SGML objects, what remains to be done is
establish the overall discipline of Configuration Management (CM). The intent, of
course, is not to deploy CM as an impediment to change but rather as a facilitator of
orderly, effective and timely change. With SGML objects that have been defined with
the intent of managing "functional objects", it becomes a natural extension to
implement the change review and status accounting practices that derive from
applying CM to these objects. Because data structures and functionality are
encapsulated together in the SGML objects, it is possible to discretely identify the
variability tolerance of different SGML elements within an object. As an example, a
proposed change to the mixed content model for English text (e.g. changing the use of
attributes within the emphasis element) may introduce processing complexities that
would very quickly indicate that the cost of altering the corporately-shared applications
outweighs the perceived benefits of the proposed change. Due to the number of
applications that depend directly upon a predictable structure within the base text
elements of an instance, the variability tolerance of the SGML object encompassing
these base elements may be, in general, determined to be low. Other SGML objects,
however, may be far more tolerant of variations and in fact support a large number of
implementation-specific element variants. This is the critical point about the
application of CM to SGML objects. With the proposed approach, requested changes
are reviewed in the context of the real impacts of that change. If a proposed change
(such as the introduction of a Program-specific content element) requires only minor
changes to a single shared application then the change could be rapidly approved with
the proviso that the requesting organization fund the minor changes so as to retain the
benefits of the impacted shared system. This is the type of interaction between local
implementers and corporate standards that encourages participation in the corporate
change management process rather than forcing Program offices, with set budgets and
schedules, to "drop out" of the process due to unresponsiveness or unreasonable (i.e.
unfounded) constraints. This is in distinct contrast to some change management
philosophies that treat any change request as a threat to the free world.
4.3: Shared Development Environment (SDE)
Responsiveness becomes a key aspect in determining whether or not a
corporate change management process for SGML objects is ultimately successful in

9. accommodating necessary changes while protecting the benefits of corporately-shared
applications. The desirability of responsiveness to local implementers attempting to
address real requirements has the effect of making the change management process
itself a corporately-shared application. It is for this reason that DND is proceeding with
plans to implement a comprehensive SGML Registry and Repository (SRR) system
where implementers will directly access SGML objects and, as necessary, initiative the
change review processes associated with these SGML objects. It would be a deliberate
move to name this shared application a Shared Development Environment (SDE) as
opposed to a central change management process. This would make it clear that the
SDE is a resource to be used by Programs in implementing higher quality SGML
applications. In effect, this would recognize that the value of corporately-shared
applications is the product of effective usage which is itself the product of the
responsiveness and effectiveness of the SDE. Understanding the SRR as a SDE would
also recognize the reality that local implementers within Programs will deviate from
using corporate SGML objects as soon as the price of compliance and foregone
functionality outweighs the benefits of the corporate applications. The operation of
the SDE becomes a service to SGML implementers.
4.4: A Typical SDE Process
An example will serve to illustrate how the SDE would function. Suppose that we
have been asked to form a DTD development team to address the publication
requirements of a new piece of communications equipment. To date, we have had
little or no exposure to the departmental information management and publications
bureaus. After a few inquiries, we learn of the existence of the SGML Registry and
Repository and its availability as a Shared Development Environment for use by the
team. Accessing the SDE, we encounter a vast repository of information regarding
corporately-shared applications that can be used to address our requirements. We also
discover that we are not alone and that there are other Program initiatives that, from
the documentation available, appear to share a remarkable similarity to our own.
Once the appropriate resources have been added to our DTD team, we begin
the obvious task of accessing how many of our requirements are addressed by the
available SGML objects. We discover that the publication specifications called up in our
supplier contract are automatically supported by in-house publishing systems if we
adopt the corporate SGML object for base text elements including tables. This makes
our first decision, that of adopting this particular object, an easy one. Further analysis
indicates, however, that we do have a requirement for a set of content tags that are
very specific to the target piece of equipment although many of the available content
tags, such as those addressing standard maintenance procedures, will suit our
purposes perfectly.

10. The DTD team directs its energies to modelling these unique features. The DTD
team makes extensive use of the online reference material provided by the SDE. The
team finds industry-adopted DTDs for comparable communications equipment and
borrows heavily to address our requirements. The team also finds a DND SGML object
that embodies content elements that are closely related to those we seek to develop.
The team decides to address our requirements by customizing (through augmentation)
this SGML object. Once this modelling is complete, we assemble the building blocks into
what will become our DTD. We are ready to invoke some of the services of the SDE.
The DTD team electronically submits a request for a specific range of services
from the SDE administrators. Firstly, we would like a technical review to be performed
on our DTD. This review will test our DTD for validity, using multiple parsers,
compatibility with multiple commercial applications used in the Department, and for
processability by corporately-shared applications such as publishing services.
Simultaneously, we request that the variant of the SGML object that we have created
by adding new elements to an existing SGML object be considered for certification as
either the new official version of the SGML object or as an approved variant.
The results of the technical review are returned to us electronically after many
of the tests have been performed programmatically based on our request. The review
includes the observations and recommendations on our content model as made by the
SDE administrator and one subject matter specialist (from another project) whose
input was solicited by the SDE administrator. One section of the review highlights
where the approach that we have taken will pose some difficulties for shared
applications. The report specifies what applications are effected and in what way.
Many of the recommendations received in fact identify changes in our content model
that would resolve the difficulties while still meeting our intended objectives.
As a separate event, we receive a detailed response to our request for
certification. The certification response includes input from a variety of stakeholders,
all of whom are currently using the SGML object that we are proposing to modify. The
certification response indicates that all critical issues raised by the stakeholders or by
incompatibilities with corporately-shared applications will have to be resolved if the
request is to result in a new version of the SGML object being certified. If, after further
analysis, unresolved issues remain related to specific stakeholders but all
incompatibilities with corporately-shared applications are resolved, then certification
as an approved variant would be forthcoming.
From the perspective of the DTD development team, it is perfectly clear where
we stand in terms of the change management process. The apparent responsiveness of
that process to our requests has given us confidence that we will be able to address
our requirements while also participating in, and benefiting from, corporately-shared
SGML applications.

11. 4.5: SDE Performance Metrics
There are two critical features of the Shared Development Environment (SDE)
for SGML objects. Firstly, the reusable SGML objects, reference information, and
support services must be value-added to the degree that Programs and new SGML
initiatives will, by accessing the SDE, automatically reduce the cost and risk of their
own SGML implementations. Secondly, the responsiveness of the SDE to requests for
information, services or certification must be optimized. Time is one of the most
precious commodities in any Program. Unless implementers can determine that the
entire SGML SDE and change management process is supporting them and their
requirements, and doing so in a timely fashion, then the willing participation of those
implementers will not be forthcoming. The process, as a result, will break down. All
corporately-shared applications that rely upon some measure of uniformity in SGML
implementations within the department will be at risk.
The ability of the SDE to gather performance metrics will be an important
feature. The SDE must monitor response times for service requests, the development
times for new SGML objects, and the process cycle times for certification and change
request review. The SDE will be designed to be continually adapting and improving.
The administrators of the SDE must be oriented toward introducing improved
automation such as automated workflow to distribute input requests to stakeholders
of an impacted SGML objects. Performance metrics will provide the best mechanism to
determine the effectiveness of the SDE and the departmental SGML strategy. It is the
best way to ensure, through proactive corrections to the process, that the benefits
realized today through corporately-shared applications are realized tomorrow.
5: Conclusion
Systems, like life forms, must adapt to survive. This truism underlines the basic
approach being taken in DND to managing investments in SGML objects and shared
applications. The value to the enterprise of the savings and efficiency gains offered by
just the SGML initiatives underway today, makes it imperative that we get the
management of departmental SGML objects and applications right. It becomes
apparent that the most important of the corporately-shared applications is the change
management system itself. A successful change management system will ensure that
SGML objects, shared applications, and Program and user requirements evolve in a
coordinated manner. To be successful, the change management system must be
responsive to new requirements as well as being highly attuned to its own
performance. Given the general objective of coordinating SGML projects to maximize
corporate benefits, the change management system must be fully "adaptive", adjusting
its operations to match its performance to the demands of the environment. It must be
granted that establishing a management regime that strives to protect corporate

12. benefits by effectively, and proactively, supporting local initiatives is both technically
and culturally challenging. Unfortunately, it is also the only approach that has any
chance of success. To return to our guiding truism, where change and variability are
part of the environment, systems, like life forms, must adapt to survive.
5.1: Cultural Issues
As a final note, we should emphasize that there are two major cultural issues
that present themselves when we consider this approach. The first issue pertains to
Programs. Programs must be encouraged to actively participate in the established
corporate processes rather than budgeting and planning for maximum self-sufficiency.
Within the typical Program office, the general desire to reduce risk by limiting
dependencies on matrix organizations often manifests itself as a genuine belief that
their requirements are unique, and therefore cannot be supported by a corporately-
shared application. This inclination must be replaced by the desire to reuse what is
available and specifically address what is actually unique.
The second issue pertains to the central agencies that are typically called upon
to administer standards and shared applications. These organizations have existed for
many years and have survived the continuous pressure to reduce overhead by
establishing their indispensability as guardians of standards and policies. For many of
these organizations it is the protracted dialogue on waivers and change requests that
gives them organizational life. In the near future, however, this type of role will no
longer be tolerated within streamlined enterprises. What will be tolerated, even
demanded, will be proactive coordination services such as those described for the SDE.
The cultural shift for these organizations will be a change in how we understand the
value of standardization. Effective standardization will no longer be measured by
effective enforcement. Effective standardization will be measured by effective usage
and by the benefits achieved thereby. It is a very new world for many who are familiar
with older operational paradigms. However, to re-use our truism in a slightly different
way, life forms, like systems, must adapt to survive.

13. Epilogue
Looking back on this, from the vantage point of 2016, we can see several noteworthy
things in this article. For example, we see how a large enterprise came to view
document content in terms of modular content models and element variants. We also
see the vital importance of associating these constructs with application behavior
without which it is impossible to meaningfully assess or manage those constructs
(following the logic of formal functionality-grounded Configuration Management).
It is probably worth noting that armed with these best practices, the DND CALS Office
was able to effectively address complex multilateral information challenges across
NATO where other markup standards (specifically the Department of Defense’s library
of CALS markup standards) had proven unsustainable.
It is also worth pointing out that the markup standard that evolved as a result of this
effort, the DND CALS Document Type Definition (DTD) and shared application suite,
prefigured many of the core tenets now seen in the Darwin Information Typing
Architecture (DITA). This should be taken as a corroboration and validation of DITA as it
shows how similar ideas will emerge to address similar problems and how those
problems are widely experienced by organizations large and small.
- Joe Gollner (2016)