Does FrameMaker 7.0 Work Well as an XML Editor?
Technical publications departments became excited when they heard that Adobe planned to release an XML-compliant version of their popular desktop publishing application, FrameMaker. Departments would be able to convert their documents in previous versions of FrameMaker to FrameMaker 7.0, and voila-instant XML. Now that the buzz has died down, departments are trying to decide if it’s worthwhile to upgrade to FrameMaker 7.0 or if a dedicated XML editor will be a better solution.
Assuming you’ve decided that XML is the way to go, I’d like to challenge you by asking you to reexamine your motives.
Did you decide to migrate to XML to
- create small pieces of reusable content
- keep your content separate from format
- get your writing staff out of the business of “tweaking” deliverables
- automate your publication process
- deliver customized documentation to the end user
XML can do all these things in the context of the right process and the right solution (an editor, a content-management system, and publishing tools). When choosing the right XML editor, you must take into account the impact on your staff, the portability to standard publishing tools, and the ease with which you can convert your existing unstructured FrameMaker documents.
Impact on Staff
If you’re like many managers, you may prefer to use FrameMaker 7.0 because your staff already has years of FrameMaker experience and you’re afraid that moving to a traditional XML editor like Arbortext Epic Editor or SoftQuad XMetaL will mean a steep learning curve. The FrameMaker interface, as it relates to unstructured content, is very much the same, but Adobe has added menus and views to facilitate structured writing. Those menus and views are similar to the menus and views in Epic Editor and XMetaL.
In comparison with other XML editors, FrameMaker 7.0 uses a proprietary system to enforce the structure of the XML document, Adobe’s version of a DTD (Document Type Definition). Although the DTD1 is the W3C standard for validation2, Adobe has chosen to move forward with EDDs (Element Definition Documents), which they originally created for FrameMaker +SGML.
EDDs, unlike DTDs, serve as a formatting template and are saved as an .fm file. Other XML editors strictly separate the validation document (a DTD) from the on-screen formatting mechanism. Epic Editor, for example, uses FOSIs (SGML style sheets) to create on-screen and output formats, and XMetaL uses Cascading Style Sheets (CSS) to create on-screen format.
The differences derive from the original product designs. Because FrameMaker’s roots are in the desktop publishing world, Adobe uses the FrameMaker proprietary format. Even though you can save documents as valid XML and edit valid XML content in FrameMaker 7.0, the product saves content by default as a FrameMaker document and validates using another proprietary format, the EDD. Epic Editor, on the other hand, has its roots firmly in the SGML world, using W3C standards for validation, the DTD, and SGML formatting options, FOSIs. XMetaL was developed initially as a techie’s tool for editing Web content and as a result the product uses DTDs and the Web styling standard, CSS. While Epic Editor and FrameMaker tend toward a document-centric model, XMetaL tends more toward a data-centric model. These different models account for the different approaches taken.
Anyone know an EDD or FOSI expert I can hire?
Using the proprietary and non-standard EDD forces technical publications departments to grow their own experts because expertise isn’t likely to exist in an applicant pool. Be prepared to invest training dollars and time into developing EDD experts if you decide to use FrameMaker 7.0. DTD experts abound, while EDD experts are still relatively rare.
On the other hand, if you purchase a dedicated XML editor, like Epic Editor, you will find that while you will not need to hire an EDD expert you will need to hire a FOSI expert instead. FOSIs are needed to provide some on-screen formatting for your writers and create formatting instructions to generate your deliverables. Again, hiring or training an employee to become a FOSI expert can also be an expensive and time-consuming task.
What about automating production?
The strength of the FrameMaker 7.0 product is its ability to publish in almost any format using Quadralay WebWorks Publisher and existing FrameMaker property sheets. Many small technical publications departments can continue to work in much the same way they have been working. Technical writers create the content and publish directly from FrameMaker.
Although maintaining a “one writer does all” solution may be all right for very small technical publications organizations, perpetuating the same writing process for a larger organization or an organization hoping to automate its publication process is wrong. One of the greatest benefits of XML is the possibility to automate production. In a larger department that can staff production specialists, you can truly separate content from format and allow your writers to concentrate on content accuracy, usability, and structure. Rather than taking weeks to properly format and “tweak” deliverables, the production process takes place separately from the writing process and take minutes rather than weeks.
Is there an interim solution?
For departments hoping to move to a full-scale content-management solution that includes automated publishing, FrameMaker 7.0 may be a logical interim step. Developing a validated Information Model and creating a DTD (or EDD) can be a long, painstaking process. Until your department can purchase the proper tools, you may want to develop and validate your process. Because FrameMaker still has all the publication capabilities your staff is used to, your deliverables can be created in the same way they have always been created.
Portability to Publishing Tools
Using FrameMaker 7.0, authors can create structured documents that validate against EDDs, but saved the content as a FrameMaker document. Authors can save content outside of FrameMaker as valid XML and later open and edit the XML using FrameMaker 7.0, but only after they’ve created an EDD.
If you’ve saved your content as XML from FrameMaker 7.0, you will also need to generate a DTD from FrameMaker 7.0 if you want to share your information with someone using another XML editor or validate your content during the publication process. An EDD will not work with any other XML editor or tool. But if your content is valid XML, any XML publishing utility with the proper style sheets can automatically process the XML generated with FrameMaker into deliverables.
FrameMaker 7.0 can also work as an interim publishing utility for departments that are too small to justify hiring a publication expert. Many departments have been leery of XML because they haven’t been sure how to create a quality print deliverable. With the ability to open an XML document in FrameMaker 7.0 and import (or create) styles, the main obstacle to XML print publication is gone.
Conversion from Unstructured FrameMaker to Structured FrameMaker
One of the strengths of FrameMaker 7.0 is the product’s ability to map and convert existing unstructured FrameMaker documents to XML. Conversion from unstructured FrameMaker to structured FrameMaker is a laborious task even with the most structured of content, but the process can be done without an extensive programming background, which is a huge bonus. Many companies make a lot of money converting documentation for departments because the departments do not have the programming expertise to do it themselves.
Although it is possible to begin with an unstructured FrameMaker file with FrameMaker 7.0, import an EDD, and individually assign content to XML elements, it would take a lot of time and effort. To ease conversion, Adobe has created conversion tables that can map existing format tags in unstructured FrameMaker to XML structured tags.
You can also round-trip your content from FrameMaker 7.0 to valid XML so that the content is usable by other departments across the enterprise and then import the content back into FrameMaker 7.0.
Conversions of FrameMaker documents to XML are straightforward, although converting your existing content may be a mistake. Even the most structured information in FrameMaker will be useless as XML unless it is mapped to a well-conceived Information Model. Although FrameMaker can facilitate the conversion, the ease of conversion is still affected by badly structured content.
I often recommend that departments conduct a thorough analysis of their documentation before they decide what should be converted to XML. Not all documentation should be converted, and any new information should be written according to a well-conceived XML structure and an Information Model.
What Does It All Mean?
Like every product, FrameMaker 7.0 has its strengths and weaknesses, which must be evaluated in light of your reasons for migrating to XML (see the beginning of this article) and the weighted importance of how a tool will impact your staff, its integration into the publication process, and your need for conversion from unstructured FrameMaker. The good news is that FrameMaker 7.0 has a lot of functionality that is important to technical publications departments and the product is priced competitively with other document-centric XML editors.
1. Schemas will eventually replace DTDs as the standard.
2. Validation ensures that the writer has adhered to the pre-determined content structure.