Re: document management and XML (longish)

[Bill Hall <bill -at- mds -dot- rmit -dot- edu -dot- au>]

Andy Johnson asked for experience with XML document management systems. 
 Garret Romaine asked if anyone else was moving a documentation group to 
XML and asked about migration from supporting RTF to XML.

The company I work for, Tenix Defence Systems, is currently implementing a 
complete XML/SGML document and content management system (DCMS) for 
maintenance documentation for 10 ANZAC frigates we are building for the 
Australian and New Zealand Navies. Our first implementation, for "planned 
maintenance" documents is now about 70% complete: The full data set has 
been converted from WordPerfect 5.1/5.2 to XML compliant SGML and all 
system functions tested, with work to be completed on the user interface 
and workflows. We are also almost certainly doing a second SIM 
implementation for a major armoured vehicle project for the Australian 
Army.

My current role in the project is as Tenix's technical coordinator for the 
DCMS implementation project, which followed on from my role last year as 
manager the R&D project that developed specifications for the system and 
organised the selection process. Before that I was responsible for 
developing and maintaining the WordPerfect and SGML systems used for 
authoring the maintenance documentation.

Our original corporate standard for word processing was WordPerfect (up 
through 5.2), and we developed a number of smart macro systems for 
developing and validating maintenance routines in this environment.  In 
1994 MS Word was adopted as the corporate standard, but the maintenance 
routines were left in the WordPerfect environment because of the tools we 
had developed.  As the WordPerfect system became ever more obsolete it has 
become more urgent to replace its functionality with a true DCMS 
environment.  We also have had a small group authoring technical repair 
specification documents in SGML for about four years, and over the last 
year they have begun to use additional DTDs for a wider range of documents. 
Our initial SGML tool was InContext. Late last year we moved into 
FrameMaker+SGML and see no reason to replace this with a Word-based 
environment in the ILS group. In our environment, where many of our authors 
are engineers and maintenance people rather than trained technical writers. 
 At least in the logistics area, our long term policy is to move all of our 
technical documentation (including tender responses) into a structured 
authoring environment under DTD and DCMS control.

After spending the whole of 1998 reviewing all of the DCMS products on the 
market and in the pipeline, we selected the SIM (Structured Information 
Manager) system developed locally by Multimedia Database Systems at RMIT 
University. See http:/mds.rmit.edu.au for MDS and http:/www.simdb.com for 
information on the product. Chrystal (Astoria) didn't want to bid, and 
BladeRunner wasn't far enough along the track for us to consider going with 
that. We looked closely at XyEnterprise's Parlance and Texcel's IM (now the 
DCMS part of BladeRunner), and certainly considered all of the info we 
could glean from the Web for any other product with a Web presence. Major 
considerations in our selection were system capabilities, initial cost, 
risk, and the maintenance and support requirements to scale the system up 
to cover more users and document types. SIM was the clear winner on all 
counts against all products except initial cost against one of the products 
because we are wearing some development costs with SIM.

Since BladeRunner has been mentioned in other responses to Andy's question, 
based on my long experience with MS Word (Word is Tenix's corporate 
standard for everything except maintenance documentation) is that this 
should be avoided like the plague for any project involving multiple 
authors working on long and complex documents. To be fair with the 
BladeRunner people, based on a reasonable look at the product at the XML 
Asia Pacific 99 conference, they seem to have solved Word's style problems 
by substituting Word's native functions with their own DLL - but I wonder 
about the maintenance cost to track Word's many changes through time. Based 
on fairly extensive research, FrameMaker appears to be fundamentally a more 
robust tool for long and complex documents than Word, and compared to 
BladeRunner, which requires extensive modifications to Word's authoring 
environment, our SIM implementation required no modifications to FrameMaker 
to make it work with SIM, and very little modification to SIM to support 
FrameMaker.

Because SIM is a local product, we have been able to substantially 
influence capabilities that will go into the document management product 
that will be commercially released early next year. Suffice it to say that 
we have every reason to believe that the commercial product will meet all 
of our document and content management requirements to support discovery 
and reuse of existing content, check in/check out, version control, 
workflow, annotations, management of two way links between source documents 
and deliverables, security, web delivery, etc.

Unlike most of the other DCMS products on the market, which marry their own 
layers of applications with middleware (Omnimark, Perl, API etc.) to third 
party indexing systems (e.g., Verity), data repositories (e.g., Oracle, 
Informix) and servers, the entire SIM application comes from the one source 
and all of its components are highly integrated within a single maintenance 
environment. SIM's repository was developed from the ground up specifically 
to manage structured data (XML, SGML or MARC). Because of this optimisation 
SIM is highly scaleable and blindingly fast by comparison to its 
opposition, which accounts for some of its existing clients.

SIM also has a completely integral and fully XML, SGML and RTF aware object 
oriented application construction environment and toolkit known as Ace. The 
conversion of our maintenance routines to XML was done first with a small 
WordPerfect macro which cleaned up some of the authoring inconsistencies 
and saved the files as RTF, and then the RTF was easily converted to XML 
down to the sub-paragraph level based on Ace's understanding of RTF's 
whitespace conventions. It took an OO programmer with no prior Ace 
experience about 3 weeks to prototype the conversion process to 
successfully convert about 60% of the records. The current process converts 
about 99% of the existing 7,800 maintenance records with no manual 
intervention. It should also be noted that there had been no control and 
little editing of the paragraph text, so the conversion process had to deal 
with a lot of 'noise' where the paragraph structure was concerned.

Existing publicly accessible SIM implementations include:
o  the Australian Tax Office - http://www.ato.gov.au/ - who also have a 
much
    more extensive intranet including legal digests and information they do 
    not make available publicly;
o  the entire legislature of the state of Tasmania - 
http://www.thelaw.tas.gov.au/,
    where the legislation is drafted, reviewed in RTF, converted to XML and 
    served to the world as the official current and past point-in-time text 
of the
    law via the Web - all within the SIM environment;
o  Macquarie Publishing's dictionary, encyclopedia and academic products -
    http://www.dict.mq.edu.au/index.cgi; and
o  Standards Australia -
    http://www.standards.com.au/news%2Dflash/1999/19991102/19991102.htm,
    where ISO standards are now available over the Web.

Other SIM clients I know about include the peer review system for the 
Department of Education, Training and Youth Affairs Australian Research 
Council grants (comparable to the US NSF) - 
http://www.simdb.com/simdb%20content%2FSolutions%2FCase%20Studies%2FDETYA; 
the Victorian Education Channel - 
http://www.simdb.com/simdb%20content%2FSolutions%2FCase%20Studies%2FEduc  
ation%20Channel; national security agencies in the US and Australia, and 
two US-based airframe manufacturers.

To support its US clients, SIM already has a US distribution and support 
agency, Kinetic Technologies, Inc. http://www.kti.com/, and I believe KTI 
will be able to demonstrate the product at the XML 99 conference in Philly 
next week. At least two people are attending the Conference from MDS.

The thoughts above are solely my own, and do not represent any official 
position which may be taken by Tenix or RMIT.

Regards,

Bill Hall
Documentation Systems Specialist
Integrated Logistic Support
Naval Projects and Support
Tenix Defence Systems Pty Ltd
Williamstown, Vic. 3016 Australia
Email:	bill -at- mds -dot- rmit -dot- edu -dot- au (Tenix DCMS Implementation Project at RMIT)
	hallb -at- tenix -dot- com (after December 17, 1999)