A FrameMaker Solution to the XML Problem (Long)

[Daniel Emory <danemory7224@xxxxxxxxxxxxx>]

THE EMERGENCE OF DESKTOP PUBLISHING
In the early 1980s rudimentary computer-based word
processors came along, giving writers, for the first
time, a semblance of direct control over the
appearance of their published work. All of that
changed, beginning in the late 1980s, with the
introduction of true desktop publishing systems, which
gave writers complete control over every aspect of the
appearance of the final printed output. A renaissance
period ensued during which the new power of desktop
publishing was exploited to greatly improve the
readability and effectiveness of technical
documentation, as well as greatly improving the
productivity of authors. 

THE EMERGENCE OF PDF AS AN ON-LINE VIEWING AND
PRINTING STANDARD FOR TECHNICAL DOCUMENTS
Nearly all desktop publishing systems today include a
capability to convert documents to PDF. Most computers
worldwide have the free PDF reader installed. On the
web, a large percentage of technical documents
exceeding more than a few pages are provided in the
PDF format. Anyone can develop a PDF converter using
that standard. The huge advantage of PDF over other
viewing methods is that it can completely preserve the
formatting and layout of the original document
produced by any desktop publishing system, even
including the embedding of all fonts used in that
document.

THE EMERGENCE OF XML
It?s essentially the same as SGML. The main changes
are intended to make it more compatible than SGML with
document storage in a database. The old and cumbersome
DSSL/FOSI methodology was replaced by an equally
arcane and difficult set of tools including XSL
Stylesheets and ?formatting objects? which are needed
to restore some semblance of formatting and layout. In
addition, XSLT provided a new capability to transform
a document?s structure from one DTD/schema to another,
including supplying the correct formatting information
for the new structure. Like SGML, XML had the
following disadvantages:

1. The gains in the readability and effectiveness of
technical documentation made during the desktop
publishing renaissance is lost because authors no
longer have any control over formatting and layout,
and their judgement is replaced by one-size-fits-all
XSL style sheets, usually developed by non-writers
such as IT weenies.

2. The cost of replacing proprietary desktop
publishing systems with XML-compatible, PROPRIETARY
authoring and XSLT-driven output engines can be
astronomical.

3. The opportunity for great improvements in authoring
productivity and effectiveness offered by WYSIWYG
desktop publishing systems is lost 

Raw (i.e., tagged) XML should never see the light of
day outside a database. By that I mean the XML
retrieved from a database ordinarily goes straight to:
(a) a PROPRIETARY XML-aware authoring system for
editing, or (b) a PROPRIETARY XSLT engine which may or
may not translate it to a different structure, and
also attaches an XML stylesheet to it to restore the
formatting

As you can see from the foregoing, all of these
required processes (as was the case with SGML) deprive
authors of any ability to control the formatting and
layout of the deliverable versions of the documents
they prepare. In fact, the stylesheet used by the XML
authoring software may be entirely different from the
stylesheet used when an XML instance is printed,
PDFed, or sent to an on-line web browser.

And even at their fullest (and extremely expensive)
implementation, the formatting capabilities of those
XML tools fall far short of what can be more easily
achieved by most desktop publishing systems. It?s
highly unlikely, for instance, that XML tools can ever
successfully format complex tables, determine, for
each page, what page layout should be used, insert
essential running header/footer information and
correct page numbering, or restore the correct
autonumbering to lists, figures, tables and heading
titles. Nor can those tools generate hypertexted
tables of contents, multi-level indexes and other
types of generated lists, which also reference page
numbers for printed output.

A FRAMEMAKER SOLUTION TO THE XML FORMATTING DILEMMA
Format rules in an EDD can be written so that the
formatting details in each context are specified by
Format Change Lists. All of these format change lists
can be placed at the very end of the EDD, grouped into
titled categories. Consequently, many variations in
formatting for the same EDD can be implemented simply
by creating multiple instances of format change list
sets, and inserting the applicable set.at the end of
the EDD, and then exporting each version of the EDD to
a separately-named template.

To implement this scheme, Adobe would create a special
server version of FrameMaker (without any authoring
capability). When a user issues a request to a
database or Content Management system for a particular
chunk of information (or an entire document),
middleware provides the requester with the available
XSLT transformation options (if any), plus the
available formatting options, as well as output
options (e.g., a PDF or FrameMaker file) for that
chunk or document. When those options are selected by
the user, the middleware issues a job ticket (and the
user-requested XML instance) to the FrameMaker server.
The server selects the corresponding template, imports
the requested document or chunk into it, and then
sends the resulting output file (with the job ticket
attached) back to the middleware for delivery to the
end user.

I believe such a solution would make FrameMaker the
pre-eminent XML authoring and delivery system. It
would wipe out all the competition, because it
completely eliminates the need for all the burdensome
and inadequate XML formatting tools required by those
competitive products. 

This opportunity should also re-invigorate Adobe?s
interest in further improving FrameMaker?s XML
capabilities, including the absolutely necessary need
for Unicode support, plus major improvements in
FrameMaker?s XML import/export capabilities.

Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
DW Emory <danemory7224@xxxxxxxxxxxxx>

** To unsubscribe, send a message to majordomo@xxxxxxxxx **
** with "unsubscribe framers" (no quotes) in the body.   **