Re: Conversion of Word documents to structured frame documents

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 11:28 AM 4/5/99 +1000, Marcus Carr wrote:
>
>Dan Emory wrote:
>
>> The ideal solution (which I'm exploring) would be to develop a complete
>> FM+SGML application pack for RTF-DOC, using the SEMA tools for round-trip
>> conversions between XML/SGML and RTF.
>
>I spend half my time convincing people that trying to round trip between
SGML and
>anything unstructured is basically a waste of time - why do you feel it
would be so
>valuable? The thought of the maintenence of such a system alone gives me a
headache.
=====================================================================
>From a purist viewpoint, I agree with you completely. But at least in the
US, MS-Word is the de-facto standard in a majority of companies, and the
small minority of people in such companies who use an alternative product
such as FrameMaker are constantly in danger of being ethnically cleansed for
their deviation from that standard.

In such an environment, mind-numbing though it may be, round-trip
conversions to and from Word is often the minimum requirement expected from
any alternative DTP product such as FrameMaker. There is a continual stream
of postings from people (one recently from your country, Australia) who are
being required to justify their continued use of FrameMaker, mainly because
it can't successfully and reliably round-trip to/from the many versions of Word.

If the RTF-DOC DTD and the SEMA toolkit could solve the round-trip problem,
then the main objection to using FrameMaker within an ocean of Word users
might diminish.
==========================================================================    
>
>> But if the RTF-DOC DTD becomes a de facto standard, the SEMA toolset could
>> very well result in the demise of FM+SGML, since MS-Weird, rather than
>> FM+SGML, would provide a viable authoring and print engine for structured
docs.
>
>Not really - it's unlikely that users would author in one application, save the
>file, fire a process, open the resulting file in another application, then
validate
>just to find errors.
======================================================================
Not just to find errors, but also to make corrections and additions. Suppose
an engineer who only has Word uses it to produce design documentation that
is the basis of a user manual created by a tech pubs dept. that uses FrameMaker.
Or, that same engineer uses Word to produce input for a proposal being
prepared by a proposal group that uses FrameMaker. In either case, an
unreliable conversion to FrameMaker could corrupt the information he
produces. Then, after the group using FrameMaker finishes polishing and
formatting the information, it must be submitted for review by that
engineer. The engineer doesn't want to mark up a paper copy, he wants to
make the needed technical corrections and additions in the document itself.
Several such review cycles are typical in such an environment, each
requiring a round-trip between FrameMaker and Word.
=========================================================================
>In my experience, users want interactive tools that guide them
>through the structure and validate on command, not a kludged-together
system. >Within
>the first five minutes, most would ask "Why don't we just author in
>FrameMaker+SGML?"
=====================================================================
But if the company standard is MS-Word, the answer will be: No Way!
===================================================================
>> The tepid XML export capability in FM+SGML 5.5.6, combined with the fact
>> that it can't import XML docs, shows that Adobe can't seem to keep up with
>> the rapid pace of XML evolution. That fact suggests that the use of
>> third-party conversion tools such as SEMA's is where the future lies if
>> FM+SGML has a chance of surviving.
>
>Whoa, steady on - what's "tepid" about the export? Why can't it import XML?
All you
>have to do is provide an SGML declaration that makes the XML syntax valid
SGML (I
>can provide one if you like). Adobe's XML development is light years ahead
of any
>other XML editor - I put it at the top of the heap, bar none. Can you cite
>applications that are better or more conformant? What is it lacking that
you need
>now?
=====================================================================
My understanding is that if a structured document was created with FM+SGML,
and you want to export it to XML, you must use the Create and Apply Formats
utility, which creates new paragraph tags for each EDD-specified variation
in the base paragraph format. Then, you must map each such paragraph tag in
the same manner that's required for converting an unstructured doc to HTML.
If I'm incorrect about this, I'd appreciate knowing about it. But if I'm
correct, then it's a tepid solution.

As far as importing XML, my understanding is that Adobe's position is that
FM+SGML 5.5.6 doesn't do it. Again, if I'm incorrect about that, I'd like to
know.
========================================================================
>
>> The holy grail of fully successful round-trip conversions between FrameMaker
>> and Word (or between FrameMaker and RTF) seems to be unattainable, as the
>> many postings on this subject confirm. And that's going to result in the
>> demise of FrameMaker as well as FM+SGML unless a solution is forthcoming.
>
>I have no idea what makes you think that round tripping is the "holy grail".
>Asserting that a continued inability to round trip with Word will "result
in the
>demise of FrameMaker as well as FM+SGML" is absurd.
==================================================================
Perhaps I purposely overstated it when I said "demise", but it's not an
absurd conclusion. Reliable round-trip conversion is the holy grail to the
many Framers in the U.S. who work in companies where thay are the small fish
in an ocean of Word users who regard Frame documents (and those who produce
them) as an obstruction to the free exchange of information, a vital
requirement for most companies. In such a company, Framers are repeatedly
required to justify their continued use of FrameMaker, and their position is
weakened by the inability to reliably round-trip between Word and Frame
without the necessity of an intolerable manual clean-up on both ends.

As it stands now, Word rules in the U.S., and Microsoft is always poised to
apply the coup-de-grace to an interloper like FrameMaker in major companies
where Microsoft Office is all-pervasive.

Even if Word's dominance is limited to the US, any significant depletion of
Adobe's installed base of FrameMaker licenses, or if the installed base
fails to grow in the US would put FrameMaker's survival in jeopardy.
============================================================================
>> Perhaps something like the SEMA toolset is the lifeboat we've all been
>> seeking. Documents that must be round-tripped between FrameMaker and Word
>> would be created in FM+SGML using the RTF-DOC DTD. In that case, FM+SGML's
>> superior capability as an authoring tool for long structured documents could
>> be fully exploited. When such documents must be converted to Word, edited,
>> and then converted back to structured docs that FM+SGML can open, the SEMA
>> toolset (or something like it) would carry out the round-trip conversions.
>
>It will never work. I have done more conversions to/from RTF than I could
count, and
>I have yet to see one dataset that works without intervention.
=======================================================================
Maybe it will work, and maybe it won't. Since neither you nor I have
evaluated the RTF-DOC DTD or SEMA toolkit, neither of us knows for sure. But
it does seem to me that a DTD that's designed from the ground up for the
purpose of round-tripping between XML/SGML and RTF, as SEMA claims, has the
best chance of succeeding.
========================================================================
>Users will break the
>rules, either maliciously or because they don't understand them, but a
>structured
>environment removes the ambiguity. If you want to round trip, I suggest you
>look
>into some of the various bolt-ons for Word to create SGML documents -
unless >you
>have structure at the source, the data will require work.
=========================================================================
Yes, a structured environment removes the ambiguity, and maybe bolt-ons to
Word are the answer in the long-run. Still, you'll have to admit that, at
least for now, most Word users (as well as FrameMaker users) are afraid of
the structured approach, and won't change their mind about it until they're
forced to.

Meanwhile, everyone will have to make do and muddle through, and something
like the RTF-DOC DTD and the SEMA toolkit might help during the long
transitional period.
     ====================
     | Nullius in Verba |
     ====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
   majordomo@omsys.com with "subscribe framers" (no quotes) in the body.


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