Chrystal Embraces FrameMaker with Canterbury

December 17, 1998

Liora Alschuler and Mark Walter

The Seybold Report on Internet Publishing
Vol. 3, No. 2

One segment of the content-management market that has remained relatively stable over the past year or so, at least in terms of the niche vendors that support it, is that of SGML-based editorial systems for reference publishing. This group of vendors, which includes Chrystal Software, Poet, STEP, Texcel and Xyvision, is not getting rich in this market, but they all seem to be making a living. That's good news for professional publishers, especially those with reams of documentation or other reference documents, because strong SGML and XML support has not yet arrived in force in the Web content managers, and even when it does, there's no guarantee that vendors looking to reach a broad market will pay any more attention to the unglamorous world of reference publishing than anyone else has in the past.

But these vendors recognize that their specialized systems, which typically go into a dedicated editorial group, are unlikely to ever win adoption across a larger enterprise. To increase sales, they will have to adapt their products. At Seybold San Francisco, Chrystal, Hynet and Xyvision all took steps in that direction.

One of a handful of vendors that manage SGML and XML documents, Chrystal has had the most success in technical engineering and documentation departments, whereas FrameMaker is often used to produce printed manuals. To capitalize on its experience in this market, and to offer a document-management system to FrameMaker users who don't want SGML or XML, Chrystal has introduced Canterbury.

Canterbury takes the core Astoria engine, which runs on the Object Design database, and adapts it to FrameMaker. Using FrameMaker's api, Chrystal has written a plug-in that enables authors and editors, working within FrameMaker, to store documents in a repository rather than in the file system.

What is interesting, though, is that Chrystal infers the structure of FrameMaker documents from its internal tagging and tracks the individual components of a FrameMaker document, even though they are not encoded in SGML or XML. Editorial groups, without learning any additional markup at all, can begin to share components by reference and to track revisions at the component level. In essence, they can take a giant step forward in document management—moving beyond the file level to components—without having to first take months to develop document type definitions.

Though many document-management vendors can manage FrameMaker files the same as any other data type, very few have attempted to manage FrameMaker components. In Canterbury, Astoria is taking on that challenge in a collaborative editorial environment. If it succeeds, it could clear a path to structured document management that, until now, has been much more difficult for straight FrameMaker users to take.

Lingua for Astoria. Separately, Chrystal announced Lingua, a module for Astoria that helps streamline the task of language translation. The way it works is that during the initial translation cycle, Lingua provides the translator with the document in the base language. Once translated, the document is checked back into the system, with its reference to the base-language document intact.

As the base-language document changes, Astoria identifies the specific components that have changed. Lingua uses this information to identify components that must be retranslated. It marks the changed documents for translation and automatically copies the updated portions from the base language into each language variant of the document. The translator can then translate the new material once, and the new translations will be replicated wherever they are referenced throughout all documents in the repository.

Available now, Lingua is an $25,000 option for Astoria.