Re: A FrameMaker Solution to the XML Problem (Long)

["Jeremy H. Griffith" <jeremy@xxxxxxxxx>]

On Wed, 28 Sep 2005 10:40:56 -0700 (PDT), Daniel Emory 
<danemory7224@xxxxxxxxxxxxx> wrote a very good description
of "THE EMERGENCE OF DESKTOP PUBLISHING", and of "THE 
EMERGENCE OF PDF AS AN ON-LINE VIEWING AND PRINTING 
STANDARD FOR TECHNICAL DOCUMENTS".  I was there too,
with one of the very first computer-based typesetting
systems, written in QSPL, run on an XDS-940 mainframe,
and output using paper tape on a Mergenthaler V-I-P.  ;-)
Later I developed software to run on the first micro
using CP/M on an 8080 that drove a Linotype 202 and
subsequently an L300.  Desktop replaced a lot of that.

Acrobat was originally called Carousel before its
release, and was intended to allow transfer of editable
documents between different publishing systems.  Not
just printable, **editable**.  Adobe failed at that
effort, and dropped back to printable only.  I kept
on and developed the technology behind Mif2Go... but
I digress.  ;-)

Dan also gives a good summary of "THE EMERGENCE OF XML",
which IMHO is still emerging today.  XSL may be a bit
easier than DSSSL/FOSI, thanks to unrelenting efforts
by Mike Kay and Jeni Tennison on-line on the XSLT-List,
but it's not something most mere mortals are ready for.

And I totally agree with Dan that:
>It?s highly unlikely ... 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.

The fundamental reason is simple.  The whole point
of SGML and XML was to separate content from format.
It's a religious issue.  If you got rid of that
pesky formatting, the purity of the content would
shine forth and bring about univeral enlightenment.

Unfortunately, when you get rid of the formatting,
you wind up with something like a typewritten draft.
(Remember typewriters?)  This doesn't look pretty
enough to release, so you have to add the formatting
back in.  XSL (XSLT + XSL-FO) attempts to do that in
a universal way.  As one might expect, the result is
"lowest-common-denominator", tolerable for phone books
but not for technical journals, let alone doc sets.
Some people use Apache's FOP to produce PDFs, but
the results are just not up to professional quality
standards.  Maybe they will be someday, but for now
Adobe has nothing to fear WRT Acrobat sales...  <g>

Then Dan suggests a solution based on structured
Framemaker that looks interesting: "A FRAMEMAKER 
SOLUTION TO THE XML FORMATTING DILEMMA".  The
kicker comes with: "To implement this scheme, 
Adobe would create a special server version of 
FrameMaker"...  Perhaps Adobe will get around to
supporting Unicode in FrameMaker someday, but a
whole new product based on it... well, it would
be good to see, but I'd expect flying pigs first.

I like Dan's vision here:

>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. 

When you consider all the possible uses of tech
documentation content, the use for print involves
way more tuning and fine adjustment of formatting
than any other.  So it makes sense to me that the
print form be the master source.  Given that view,
the rest of the possible forms -- including XML --
are best derived from print, or in this case MIF.

Which is why I think WWP and Mif2Go have a long
life ahead of them.  Adobe's improved XML support
(for structured docs *only*, mind you) may serve
some needs, but it will never do the job for
producing professional on-line Help, no matter
how good people are with XSLT... there's too
much that just can't be done by such transforms.

And conversion to Word, which Mif2Go does very
well, is entirely beyond the reach of XSLT...
even considering Microsoft's claim of native
XML usage for the next version of Word.  While
new PDF features in Acrobat 7 Pro may handle
review needs for some, others will still need
to pass Word versions of the Frame docs around
for engineering review... and those versions
need to look just like the Frame docs.  You
can't do that by discarding Frame's formatting
(as required going to XML) and reconstituting
it in Word using Word's formatting methods...
the equivalent processes just do not exist.

>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.

As things are, I expect that any major improvements
are going to come from third parties.  I note that
the new DITA support in Frame came from Kay Ethier,
who has been ably running the [framemaker-dita] list
for some time.  I'm glad Adobe paid attention to her.
That support is probably the largest single improvement
in FM 7.2; multiple undo is nice, but I'm a bit wary
of it (and no, I'm not a beta tester).  Perhaps we
will see Adobe do some more shopping for the next
revision.  But then again, when Microsoft buys an
add-in for one of their products, they kill a whole
little market.  Adobe doesn't have the volume to
attract new vendors to the Frame plug-in market,
unlike Microsoft, so such a strategy could prove
counterproductive for them.  I don't envy Adobe...

Thank you, Dan, for your commentary.  I always
appreciate your perspective and analysis!

-- Jeremy H. Griffith, at Omni Systems Inc.
  <jeremy@xxxxxxxxx>  http://www.omsys.com/

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