May 1998 : Combining Architectures to Lower the Lifecycle Cost of Interactive Documents with Substantive Behaviours

Information Management - Who gets the benefits		Table of contents		Indexes		Session chairs:


	Combining Architectures to Lower the Lifecycle Cost of Interactive Documents with Substantive Behaviours

Steven R. Newcomb

President

TechnoTeacher, Inc.
3615 Tanner Lane
Richardson Texas USA 75082-2618
Phone: +1 972 231 4098
Fax: +1 972 994 0087
Email: srn@techno.com Web: http://www.techno.com

Biographical notice:

Steven R. Newcomb, Ph.D.

Founding President, TechnoTeacher Inc., 1984-present. TechnoTeacher supplies software technologies, collectively known as the GroveMinder, MarkMinder, HyMinder, (etc.) Systems, on which sophisticated, state-of-the-art electronic information management applications have been built by such customers as the U.S. Navy, Fujitsu Ltd., and others. TechnoTeacher's technologies and services emphasize the ISO/IEC 10744:1997 "HyTime" standard and the SGML Extended Facilities described in its Annex A.
Project co-editor (with Charles F. Goldfarb), ISO/IEC 10744:1992 Hypermedia Time-based Structuring Language (HyTime). This standard is an application of Standard Generalized Markup Language (SGML), ISO 8879:1986, whose project editor (and inventor) is Charles F. Goldfarb. Project co-editor (with Charles F. Goldfarb, W. Eliot Kimber , and Peter J. Newcomb), ISO/IEC 10744:1997, the HyTime Second Edition.
Design Team Member, MID (Metafile for Interactive Documents, U.S. Navy) Project, 1994-96. MID is a language (and an application of HyTime) for the logic and abstract presentation semantics of interactive electronic technical manuals (IETMs). It is intended to allow all IETMs from all weapons systems suppliers to be presented by all military IETM delivery systems, and to allow the information content of IETMs to be automatically assembled from heterogeneous databases. This work culminated in a working model of a MID- and HyTime-conforming IETM delivery system called HyMID. HyMID contains version 0.8.4 of TechnoTeacher's HyMinder technology.
Founding Conference Chair, GCA International HyTime Conference, Vancouver, B.C. in July 1994 and August 1995, Seattle in August 1996, Montreal in August of 1997 and 1998.

Fujitsu

GCA, Graphic Communication Association

Interactive Electronic Technical Manuals

International HyTime Conference

Kimber, W. Eliot

MID

MarkMinder

Metafile for Interactive Documents

Montreal
Navy
Newcomb, Peter J.

TechnoTeacher

US Navy

ABSTRACT:

Metafile for Interactive Documents

SGML Extended Facilities

simulation

It is expensive to maintain long-lived documents that include behaviours that are part of their substance. By representing such documents using inherited architectures for program logic, etc., validation can be facilitated, reliability improved, and costs minimised.


	Introduction

Many electronic documents exhibit behaviors that go beyond the book metaphor, and some of the behaviors of some electronic documents are parts of their essential substance. Protecting and maintaining such "substantive" behavioral information in long-lived interactive documents presents exceptional challenges, risks, costs, and opportunities.

document management

This paper proposes an approach whereby we may hope to extend SGML's "management umbrella" to expressions of interactive document behavior, thus allowing a more fully integrated approach to the problem of creating, maintaining and validating document sets that embody not only content, but also program logic. This approach exploits the inheritable information architecture paradigm described in the Architectural Form Definition Requirements (AFDR) section of the SGML Extended Facilities , as standardized in ISO/IEC 10744:1997 Annex A.3.

This paper focuses on the applicability of the proposed approach to Interactive Electronic Technical Manuals (IETMs), also known (in AECMA circles) as Interactive Electronic Technical Publications (IETPs). IETMs pose a major maintenance challenge on which considerable resources are constantly and increasingly expended. The substantive behaviors of IETMs may be arbitrarily complex, even incorporating training simulations and expert diagnostic systems.


	Representing Substantive Behaviors

With the exception of so-called "shovelware," all electronic documents exhibit behaviors that go beyond the book metaphor. Some of the behaviors of some electronic documents are actually part of their substance, while other behaviors are simply a matter of rendition. For example, the fact that a hyperlink is available for traversal from a particular part of a technical illustration is probably substantive information. By contrast, the means whereby a particular delivery system may indicate that traversal is available, and the means whereby the user may signal an intention to initiate traversal, are normally not essential to the substance of the document; these things are more a matter of rendition than substance.

As an example of document with substantive behavior, let's imagine an IETM for a steam engine aboard a naval vessel.

There are various parts of the steam engine that have to handle live steam at high pressure: turbines, couplings, heat exchangers, etc. Some parts have higher pressure ratings than others, and some can handle higher temperatures than others. The temperatures and pressures to which a given portion can be exposed may change over time, due to aging, exposure to stress, maintenance, damage, repairs, and system upgrades. These changes must be reflected in the operating manual, as they occur, in order to provide the engine room crew with the information they need in order to provide safe and efficient power for the ship. This particular IETM is designed to provide advice to the operators during all phases of operation: downtime, startup, standby, run, and shutdown. The manual's delivery system receives input from pressure, temperature, and other sensors, and the manual is designed to provide advice which takes all these incoming data into account. There are so many possible operational scenarios that it is impractical for all of them to be explicitly accounted for in advance by the manual's authors. The manual, therefore, must be a computer program, with variables, calculation routines, and decision logic, in addition to providing all of the information that a paper manual would have provided.

How can such a manual be created? Even more important, how can we maintain it, given that the engine room machinery is changing its operating characteristics so often, and more information is constantly being learned about how to operate and maintain it? Bear in mind that there is no room for error in this manual; live steam is very harsh stuff, and human lives are at stake.

The problem of specifying behaviors is the central problem of electronic documents, regardless of whether they are IETMs or telephone directories. There are several approaches.

One approach is to create your own delivery system . Many manuals have been written this way. The distinction between the system software that supports delivery and the technical manual information that drives that system can be whatever is convenient; one of the appealing characteristics of this approach is that no such distinction needs to be made. This approach offers the greatest possible flexibility and power, but only at high cost at creation time, and even higher cost when such a complex computer program must be adjusted to reflect updates in the manual's information. Only highly skilled people can perform such updates, and the cost of verifying that the updates were done correctly, and that no incidental damage was done to the rest of the manual, is very high. This option is unattractive because it is so costly.

Another approach is to limit the repertoire of behaviors of the document to only those behaviors that are directly supported by some chosen "commercial off-the-shelf (COTS)" delivery system. It's hard to see how our steam plant example could be supported by an HTML document running on an HTML browser, and it seems very unlikely that the complex behaviors we need are cleanly supportable by the inherent features of any off-the-shelf software product. This approach doesn't work because we can't find the behaviors we need in any existing delivery system.

Another approach is to exploit existing delivery system behaviors so that more complex behaviors are simulated . For example, bidirectional hyperlinking can be simulated on an HTML browser by using two hyperlinks, one at each end of the link. Traversal can now be initiated from either anchor. It does seem possible, although unlikely, that some off-the-shelf delivery system could be made to appear to exhibit the complex behaviors we need by providing it with documents that contain exhaustive provisions for every possible scenario. However, such documents, if they could be written at all, would likely be huge, and nearly impossible to maintain or even validate. Moreover, they would be extremely difficult to query. For example, in order to determine what behavior the document will exhibit if the temperature reported by some sensor is less than 400 degrees Celsius, all of the scenarios in which such a temperature reading occurs would have to be examined individually. It would be difficult to eliminate scenarios in which the temperature reported by that sensor is irrelevant. This option is unattractive because it's impractical.

browser plug-in
querying software source code

Another approach is to enhance an existing delivery system . This is a powerful answer to the problem of providing an electronic document with complex behaviors. It's a much less expensive approach than creating a custom delivery system "from scratch", and yet practically any behavior can be supported. One way to accomplish this is to provide a plug-in software module for each new complex behavior (or one module for all of them). The document can pass parameters to the software module that controls each complex behavior. Even though this approach is attractive, is it still far from ideal. If there are many complex behaviors, and some of them are used only once by the manual, it must be acknowledged that the software itself includes decision logic that is integral to the information represented and delivered by the manual. The behavior logic is therefore not really in the document; instead it has moved to the delivery system, where it now becomes difficult and expensive to maintain in harmony with the rest of the document. The substantive behavior-determining information cannot be validated by any ordinary querying process; once again, it can only be determined by running the manual while providing the system with various sensor inputs. The creation, maintenance and validation costs for such a manual are very high; the software and the manual that calls the software must be tested separately and together, and the skills and time of many people must be coordinated in order to accomplish such validation. It is especially worrisome that the software is written in a language which is not validatable in concert with its corresponding SGML content. Indeed, there may be no querying methodology that can validate all the possible interactions between the two classes of information.

Java

A similar, but slightly better approach is to provide special software with the document that the document "calls" via the delivery system . For example, many internet documents are supplied with Java programs that provide those documents with specialized behaviors when they are rendered. Because this approach acknowledges that the software is really part of a particular document, rather than pretending that the software is really part of the delivery system, this approach is conceptually cleaner. However, for our high-value steam engine manual, this approach still suffers from the same disadvantages as any other method of adding a class of behaviors to the delivery system: the behavioral information in the software is disjunct from the subject matter of the manual, and to whatever extent the added class of behaviors represents knowledge about how a steam plant should be operated, that knowledge cannot be maintained or validated by the same kinds of tools and procedures that are used to maintain and validate the rest of the manual. One way to find out the information that would only be revealed by the behavior of the applet is to run the applet with various inputs, and see what happens. Another way is to have a skilled programmer read the code. Both of these validation methods are human labor intensive.

Java

Since we have mentioned Java, it is trenchant to observe that Java is, of itself, no panacea for the problems faced by owners of documents with substantive behaviors. Java will change with the whims and competitive strategies of its vendors (viz. Microsoft vs. Sun); as a proprietary technology, Java is far from certain to be supported over a long-lived document's lifecycle; the tools we use to validate information in the SGML content world do not work on Java sources, and vice versa; the validity of Java applets for their associated text and graphic information is easily weakened and accidentally broken by the ongoing maintenance of such documents; and it is expensive to verify adequately that the integration of Java applets and their associated static information objects (such as SGML text) remains valid after each maintenance operation on the document. In the end, as far as content management is concerned, Java is just another programming language, albeit one with some special marketing advantages. (A methodology for handling Java code is proposed below.)

HyTime

hyperlinking

transclusion

A somewhat better approach is to use a delivery system which supports a certain fixed set of complex behaviors . The documents simply select and pass parameters into the routines that execute the behaviors. This was the idea behind the US military's MIL-D-87269 standard for IETMs. Because the number of complex behaviors is strictly limited, and because each complex behavior is simple to call and control, this approach works well. All of the substantive information in the manual is created and maintained in SGML. Powerful validation tools based on SGML and the SGML Extended Facilities can be used to validate the entire content of a manual, including the behavioral content. HyTime addressing, linking and transclusion features can be used to cut the cost of maintenance substantially, allowing new versions of IETMs to be recreated automatically, directly from databases of frequently-updated logistic information. Unfortunately, because the number of behaviors is limited, there can be no complex behaviors that are specialized for particular maintenance or operational situations, such as our steam plant.


	MID - A Radical Approach

cooking lessons

A radical approach is to use a "reduced instruction set" document delivery system whose behaviors are specified in SGML by the document . In this model, the delivery system acts as an interpreter for the document. Effectively, the document is, among other things, a computer program, with programming constructs such as variables, conditional expressions, branching, subroutines, etc. The substantive behavior logic is entirely expressed in SGML, so it, along with the other content of the document, is subject to all of the maintenance and validation tools and other advantages of SGML. (Tools that support the SGML Extended Facilities can be especially useful when exploiting this approach.) All behaviors that bear on the subject matter of the document are described by the document in SGML. There is no need for "helper applets." The delivery system does just a few basic things, so it can be as useful for delivering cooking lessons as it is for delivering maintenance information for shipboard steam plants. Although some languages designed for computer-based instruction have offered an ability to mix content with behavior for over thirty years, this radical approach has been demonstrated only once using SGML, in the US Navy's "Metafile for Interactive Documents" (MID) architecture. The design of MID recognized the need to provide a single, consistent, unifying view of the contents of documents with arbitrary substantive behavior. That view was an SGML/HyTime view, since there is no other view that can bring all kinds of content, including program logic, under one standard validating syntax-umbrella.

SHORTREF

human nature
learning syntaxes
military conflict

From the barrage of MID-opposing disinformation and nontechnical objections that have emanated from the Navy's weapons system vendors since MID was successfully demonstrated, we might reasonably conclude that, at least from the Navy's perspective, the reasons why MID has been shunned are not technical, but rather stem from fears that the widespread adoption of MID would bring unwelcome changes to their business models. That conclusion wouldn't be entirely fair, however, because:

Programmers are not thrilled about the idea of writing software in SGML; they simply do not wish to program using SGML syntax. In SGML's unadorned reference concrete syntax, the code is hard to read. True, the visually "busy" and unstructured appearance of meaningful SGML tags can be avoided by clever use of SHORTREF, but SHORTREF is not quite as powerful as might be considered ideal for this kind of purpose, and, anyway, despite the fact that SHORTREF has been around for 12 years and is widely implemented by SGML parsers, almost nobody has any day-to-day experience with it. If SGML gurus rarely use it, few programmers will ever hear of it. In any case, probably went too far by insisting that every aspect of the program logic be expressed in SGML syntax. It is evidently a matter of human nature that we resist the imposition of new syntaxes during adulthood. History suggests that language differences markedly increase the likelihood of military conflict, and there is a variety of scientific evidence that tends to support the idea that syntaxes are best learned in childhood.
Today's programmers are not usually technical writers. Programmers don't usually appreciate the advantages SGML offers for content management, and they usually don't see program logic as "just another aspect of content", even if their employers do.
Today's technical writers are not usually programmers. Technical writers may resist the idea of seeing program logic in their documents, much less actually writing it. Such a notion is unfamiliar and even threatening.
Another argument against MID is that programmer productivity depends on interactive authoring and debugging environments for programming languages, and no such tools exist for programming languages expressed in SGML.


debugging programmers technical writers	Grand Unification of Content Notations: The Perfect Approach

The "perfect" approach is to find a way to ignore syntax altogether, for purposes of document validation and software development. This approach might be described as a "Grand Unification of Content Notations". It is still science fiction today, but the theory and standards necessary to support it are now here.

In the perfect approach, we imagine ourselves working in an document-and-application development environment in which we bother to wrap up our information assets in syntaxes only when we need to interchange them. In their useful, dynamic form, our documents consist of sets of objects conforming to a single, powerful and consistent object model. Some of these objects exhibit the properties of content of the kinds normally expressed in syntaxes that are used for non-behavioral information, such as SGML, HyTime, PDF, and CGM. Other objects exhibit the properties of programming constructs such as those normally expressed in such syntaxes as Java, Scheme, or Python. All these objects co-exist in a single unified realm that provides an internationally standardized abstract API to all of the properties of each object. This API provides:

Access to the syntactic constructs that appear in each raw information asset.
Access to the semantic properties of each information asset that are not syntactically explicit, but which emerge from processing that any application would always have to do in order to do anything useful with the notation. An example of this kind of processing is, in the case of an XLL-conforming document, determining which parts of which objects serve as points from which traversal of a given "out-of-line" (in HyTime jargon, "independent") hyperlink may be initiated. The result of this processing is to make available the fact that a given traversal-initiation point is indeed such a point, as a kind of "emergent property" of the information that serves as that initiation point.
Access to all properties of all classes found in all notations in terms of names for each class and property applied in a schema-defining and abstract API-defining "property set" expressed in an internationally standardized notation.

XLL

emergent properties
independent link
out-of-line link

Once we are managing our "documents with substantive behavior" in this universalized and consistent environment, it becomes possible for the first time to run queries that can reveal all of the factors that will influence any particular behavior at any particular time. For example, it becomes possible to determine which behaviors will influence the presentation of which aspects of content. We can even determine which variables in the substantive behavior-defining software logic of our documents influence which aspects of the rendition of certain content, by means of complex queries that can treat everything found in all kinds of information assets as the contents of a single consistent object database.

Perhaps most importantly, after any change to any behavior and/or to any content, the scope of quality assurance testing can be safely limited to only those behaviors and contents that could conceivably be affected by any given change. This increased ability to focus human attention only on potential problem areas not only conserves elapsed time and human resources, but it also increases product quality and the morale of knowledge workers whose tasks will have become far less daunting and far more comprehensible than they would otherwise be. Where, once upon a time, a small change to a single class of behavior required a regressive quality assurance check on the semantic content of a hundred-million-character technical manual, now only the affected presentations need be checked. The number of practical ways to automate various semantic validation checks becomes unbounded, and these checks can involve operations requiring examination of the interaction of content and behavior at any desired level of detail.

GroveMinder

property set

The technical basis for this "perfect approach" is the "grove" paradigm recently standardized in ISO/IEC 10744:1997, some of which was already in use in the DSSSL standard (ISO/IEC 10179:1996). Although few realize it yet, groves aren't just for SGML; they can be used to represent the output of parsers for any notation, and to provide a consistent API to information expressed in very different notations. (Those who are interested in this idea may wish to follow the ongoing efforts to bridge the remaining disjunctions between SGML and STEP data. They may also wish to contact TechnoTeacher, Inc, and ask about the forthcoming "GroveMinder" technology. )


	An Approach For Today

SGML Extended Facilities

Given that the "perfect approach" is not yet technically supportable, what can be done with today's technology to better integrate content and behavior in documents, so as to minimize the cost of their upkeep? Are there any practical steps that will allow quality assurance processes to examine interactions between content and substantive behaviors? We can assume that program source code will be checked for internal consistency by compilers and other software-language-specific tools. We can also assume that content will be checked for internal consistency by SGML parsers, perhaps augmented with tools that exploit additional validation possibilities based on the SGML Extended Facilities . But the interactions between content and behavior are likely to be numerous and subtle, and such interactions will still resist testing by affordable automatic processes.

Java

We can hope to improve this situation by physically interleaving the behavior-defining code, in its own notation (Java or whatever) with the content that drives the behavior and/or whose presentation is defined by the behavior . Such interleaving offers two significant advantages:

Where content and behavior are specifically related to one another, they can appear in the same place as part of the same parsable document. This alone can be an important management advantage, and not only because such co-located things can be straightforwardly quarantined as a unit for special attention and testing when any aspect of them has been changed. It is also advantageous because all the relevant information, both content and behavior, are directly editable at the same time and in the same place by the document's developers and maintainers. It is easier to define, use, and visually verify the consistency of any interface between the content and the code if they are thus juxtaposed.
All of the behavior-defining elements (the elements that contain portions of Java code or whatever) are wrappers that can greatly assist in the management of metadata used in code management. The metadata for a function, for example, can include the name of the function, the datatype returned by the function, the datatypes to be passed to the function, the purpose of the function, etc. Most such metadata can be generated, one way or another, and then the metadata (and therefore the code that it represents) can effectively all be in the same queriable universe as the other content of the document.

Java

But simply interleaving the code with the content is probably not, of itself, sufficiently beneficial to make it worth the trouble. It becomes worthwhile to develop all the necessary wrapper element types, and to develop the software that will assemble the portions of code in such a way that they can be executed, when we can do it in such a way that all that work can be re-used in (inherited by) whatever information architecture needs to incorporate that same programming language. This will make it practical and profitable to integrate high-reliability systems for creating and maintaining structurally specialized documents whose content includes substantive behaviors.

As it stands, the MID DTD and its supporting software can't be re-used in this way.

Note:

^{Of course, MID does inherit the HyTime architecture, which is regularly re-used in commercial and government contexts, and the HyTime engine used in the HyMID prototype browser also appears in other applications.}

The MID DTD is an amalgamation of diverse notions and constructs, and it represents a particular combination of requirements and assumptions about programming techniques, programming languages and windowing display systems. For systems integrators, it is regrettable that the MID research was done before the "inheritable SGML architectures" breakthrough had arrived. The separate aspects of the MID IETM language (for example the windowing element types, as distinct from the content sequencing element types) are not inheritable separately by architectures that could take advantage of certain aspects of MID without having to incorporate all of it; using MID is an all-or-nothing proposition. For a systems integrator, the programming constructs used in MID (or in any other complex DTD) might be equally useful in an almost entirely different information architecture -- one which may not even be an IETM architecture. The ability to inherit architectures in an internationally standardized way imposes a kind of discipline that is already familiar to object-oriented systems designers: a powerful incentive to identify and formalize all useful layers of abstraction, because there is nothing to be gained, and much to be lost, by reinventing already-tested information architectures and mature software that can already be re-used without modification. In retrospect, in the case of MID, it's now obvious that we would have done better to keep each of its distinct aspects (e.g. window controls as distinct from presentation sequencing) in a distinct generalized architecture. Then we could have inherited all of these separate aspects in the MID DTD, and, more to the point, others could have more easily derived benefit from the MID development work.

Note:

^{But that was not a customer requirement, and ISO/IEC 10744:1997 did not yet exist. We did think in terms of inheriting HyTime, but we weren't yet thinking that all DTDs are inheritable.}

The SGML Architectures paradigm set forth in Annex A.3 of ISO/IEC 10744:1997 can be used to combine various distinct information architectures by inheriting them in a single architecture, such as an architecture for documents with substantive behaviors. Since each inherited architecture can be supported by a modular, reusable engine, this technique can reduce the cost of developing software for particular complex integrated applications, such as MID browsers and authoring systems.

For example, consider an IETM DTD that provides:

Element wrappers for Java functions,
a content architecture (elements for content) specifically designed to support the diagnosis and repair of consumer electronic devices that have, among other things, a certain common proprietary diagnostic harness connection,
a presentation metaphor based on Microsoft Windows, and
hyperlinking based on the XLL architecture.

If each of the above aspects of this IETM DTD is inherited from an architecture (basically a DTD) that is devoted to that aspect, then much design time can be saved. It is far more economically important, however, that the software that supports each of these specialties is also combinable into integrated systems for authoring and/or delivering these IETMs. The overwhelming majority of the specialized software of such a system is bolt-on modular "engines" that can be outsourced and that may already exist in mature, stable and reliable versions. For our proposed IETM browser implementation, there might already be:

An engine that understands Java, or at least the corresponding wrapper architecture for Java constructs at whatever level of granularity is needed,
An engine that understands how to handle data intended to be compared with data arriving at execution time via the diagnostic harness (let's call this our "inherited specialized content architecture"),
An engine that knows how to make Microsoft Windows to do whatever the data expressed according to its corresponding architecture requires, and
An XLL link resolution engine.

Nothing in this world is immune to change. However, because it is modular rather than monolithic, our IETM DTD and the software that supports it can cope with change gracefully and at minimal cost. When Microsoft changes its Windows metaphor or goes bankrupt, only the relevant aspects of our DTD needs to change, and the expense of upgrading the software to the next popular presentation metaphor is limited to the cost of bolting a new engine onto our authoring and delivery systems. The same is true for the other aspects: Java, the diagnostic harness, and XLL.

Similarly, the productivity of sophisticated systems integrators will be greatly enhanced by the methodology of inheritable architectures. Essentially the same DTD and the same presentation and authoring systems can be created with minimal effort for documents designed to teach technical skills. All that normally needs to be replaced is the specialized content architecture, if any, and the software modules that support it. The rest can stay the same, unless perhaps a programming language other than Java, a presentation metaphor other than Microsoft Windows, or a hyperlinking architecture other than XLL is required. Even if different modules are required, it is possible that architectures and engines are already available to support them, too. And even if such architectures and engines are not already available, there is the possibility that once they are developed, they can be used profitably in other projects.

Acknowledgments

Bibliography

MID1: The official report on the MID project, with the MID DTD: ftp://navycals.dt.navy.mil/pub/ietm/mid/mid95
MID2: The "HyMID" demonstration package for 32-bit Windows with demonstration documents (demonstrates an implementation of the Metafile for Interactive Documents): ftp://navycals.dt.navy.mil/pub/ietm/mid/HyMID
MID3: The author recounts some early experiences with the PLATO system and some more recent experiences with MID: "Adventures with Interactive Documents" http://www.techno.com/adventures/
HYTIME: Information about ISO/IEC 10744:1997 ("HyTime"), including a link to the complete text of the standard in SGML source, HTML, Panorama, and PDF: http://www.hytime.org .
SGMLARCH1: The author discusses the "Implications and Opportunities for Industry" of inheritable SGML architectures: http://www.techno.com/sgmlarchitecture.html
SGMLARCH2: "An Approach to Literate Programming with SGML Architectures" by W. Eliot Kimber: http://www.isogen.com/papers/litprogarch/litprogarch.html
SGMLExFac: The SGML Extended Facilities standardize the notions of both Property Sets and Groves (the "Property Set Definition Requirements ["PSDR", ISO/IEC 10744:1997 Annex A.4]), and inheritable SGML Architectures (the "Architectural Form Definition Requirements ["AFDR", ISO/IEC 10744:1997 Annex A.3]), among other things. See http://www1.y12.doe.gov/capabilities/sgml/wg8/document/n1920/html/clause-A .
SGMLARCH3: The most directly relevant portion of the ISO/IEC 10744:1997 standard governing the inheritance of SGML architectures: http://www1.y12.doe.gov/capabilities/sgml/wg8/document/n1920/html/clause-A.3.html
PSDR1: The most directly relevant portion of the ISO/IEC 10744:1997 standard governing the interchange of property set information and the nature of groves: http://www1.y12.doe.gov/capabilities/sgml/wg8/document/n1920/html/clause-A.4.html .
GROVEM1: The GroveMinder system is being developed by TechnoTeacher, Inc. with support from ISOGEN International Corporation of Dallas, Texas, USA. A brief technical description of GroveMinder can be seen at http://www.techno.com/gminder3.htm . ISOGEN's web address is http://www.isogen.com .


Information Management - Who gets the benefits		Table of contents		Indexes		Session chairs:

Combining Architectures to Lower the Lifecycle Cost of Interactive Documents with Substantive Behaviours

Introduction

Representing Substantive Behaviors

MID - A Radical Approach

Grand Unification of Content Notations: The Perfect Approach

An Approach For Today