SGML: Subdoc: Why I Demand It, an Update

Subdoc: Why I Demand It, an Update

Subject: Subdoc: Why I Demand It, an Update
Date: 18 Jun 1997 00:43:57 GMT
From: "W. Eliot Kimber" <>
Newsgroup: comp.text.sgml

At SGML '96, I presented the paper "Re-Usable SGML: Why I Demand SUBDOC" (

There have been a few developments in the subdoc world that I thought might be of interest:

1. James Clark added support for the "sgml-parse" function to the JADE DSSSL engine. This means, among other things, that a single style sheet can be applied to a tree of documents and subdocuments, either directly, or by first using JADE's SGML Transform back end to generate a single instance and then running JADE on that. I've put together a DSSSL spec, dovalueref.dsl, that does this, available from the ISOGEN demo area (

2. I have been personally involved in a large-scale implementation of subdoc-based document management and authoring. We are days away from rolling the system out to our internal customers (it's a purpose-built system). We are using subdoc-based management because it solves exactly the problems I point to in my paper. Our implementing tools are Documentum, Oracle, ADEPT*Editor, and Omnimark (not including the down-stream tools that never see the subdoced version of the documents).

3. I have demonstrated the ability to do HyTime-based indirect addressing and linking in ADEPT*Editor ( This, in addition to the subdoc-based authoring support we developed for (2), provides the necessary authoring infrastructure for developing subdoc-based compound documents. With the current ADEPT*Editor (5.4.1/W, 6.x), it requires some tricks and there are some limitations, but we have made it work.

4. I heard from several people at SGML Europe that they had implemented subdoc-based management systems with some success.

5. The Second Edition of the HyTime standard, which are proofing the final CRC for right now, defines a new facility, "value reference", which, among other things, provides a generic mechanism for indicating the intended semantic for subdocument references used to create compound documents. In fact, my dovalueref DSSSL spec uses the valueref facility to provide generic (DTD-independent) support for subdocument resolution.

Taken together, I think these developments demonstrate that a subdoc-based approach to document management is both possible and practical and can, in fact, be implemented to some degree (at least for processing purposes) using free tools, such as JADE. My dovalueref DSSSL spec pretty much puts to rest the "but no tools support subdoc" argument, because any tool that expects a single document as input can be given one at amost no additional cost, either in tools investment or time (JADE is both free and very fast). I've demonstrated that ADEPT*Editor, in particular, can be made to provide useful subdoc editing facilities. Presumably other similarly-feature SGML editors could as well (I'm sure it's possible with Author/Editor, for example).

There is still the problem of finding document management systems that will manage subdocuments for you. Documentum does it easily because all it does is manage trees of documents--it doesn't know or care about the SGML structures themselves. Other storage-object managers, like LiveLink and PDM should as well (although PDM has enough SGML smarts that it might not, I don't know enough about PDM). "Element managers" like Texcel Information Manager and Astoria don't really manage documents (in the SGML sense), so they are currently incapable of managing trees of subdocuments, although that's an easily remedied implementation problem.

I'm quite encouraged by all this....

<Address HyTime=bibloc homepage="">
W. Eliot Kimber,
Senior SGML Consulting Engineer, Highland Consulting
2200 North Lamar Street, Suite 230, Dallas, Texas 75202
+1-214-953-0004 +1-214-953-3152 (fax) (work)</Address>
"Rats in the morning, rats in the afternoon...if they don't go away, 
I'll be reducated soon..."   --Austin Lounge Lizards, "1984 Blues"