Chrystal releases Astoria 2.0

January 20, 1997

The Seybold Report on Publishing Systems
Vol. 26, No. 9

Chrystal Software, the Xerox XSoft spinoff, showed version 2.0 of its Astoria document management package, which it had just begun to ship to customers. Also new was the integration of FrameMaker+SGML with Astoria. The integration was scheduled for release this month.

Astoria 2.0. A key feature of Astoria 2.0 is the enhanced API, which permits a number of new and powerful features. For example, the API allows other applications to gain much more flexible access to the contents of Astoria’s repository. Previously, only valid SGML that parsed correctly could be retrieved. That often meant that extra “wrapper” material had to be added to document components to meet the requirements of the DTD.

Validation is often, but not always, desirable behavior for an SGML repository. For instance, you may want to assemble a document for which no DTD has yet been developed (or for which a DTD will never be required). Without the flexibility of allowing non-SGML, Chrystal couldn’t support such a requirement.

Chrystal also demonstrated how the new release provides the possibility of drag-and-drop rearrangement of large documents directly from the Astoria outline window. (Previously, this would have required loading the document into an editor, doing the rearrangement there, and then loading the rearranged version back into Astoria.)

Another new option enables document components retrieved by a search to be turned into a new document, without having to invoke an editor. Furthermore, the tools in the new API make it possible automatically to construct a new DTD for a document created in this way. (Some SGML editors require compiled DTDs to work on documents.) The new document can contain duplicates of the old components or it can simply contain pointers to them.

We like the new support for “custom attributes,” metadata about document components that are held by the Astoria database and not reflected in the SGML file. These attributes might include such things as the customer name, version number or review status. Any of these could be encoded in the SGML file, of course, by changing the DTD. But there are often situations where people working with an SGML document don’t have the authority to make DTD changes. Or they may be able to make the changes, but prefer not to because of the impact on document interchangeability with other sites. An SQL query could also be stored as a custom attribute. It wouldn't appear in the "final" document but would be used to update the document at the point of publication.