Re: Conversion of Word documents to structured frame documents

[Marcus Carr <mrc@xxxxxxxxxxxxxx>]

This is my third attempt at responding to this mail - continuous lines of equal
signs wreaks havoc on my mail app (NS 4.08).

Dan Emory wrote:

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

I believe that most people are in a head-to-head battle over products in their own
right, not because of how they interact with each other. Companies want Word because
it's free - users want FrameMaker because of its functionality. These are the
fundamental reasons and are not related to round tripping.

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

I'm not sure how much success most people would have going to their managers with
the line "If you buy the SEMA toolkit, it will enable us to justify spending money
on FrameMaker." If their managers won't accept their technical arguments for Frame
now, I don't see this as swaying them. Indeed, maybe Word is sufficient for some of
these sites, despite the enthusiasm of the users for something more powerful.

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

Without question, and that is the basis of my argument. Total reliance on any filter
is likely to ultimately result in heartache. Remember the Word 7.0 "Save as Word
6.0" fiasco? Word was saving as RTF, because it couldn't remain binary campatible
with itself.

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

The documents are nearly perfect, but Eddie Engineer wants to change two things:

 a)  at the end of a list, he decides to add a paragraph that explains the weighting
of the items. He puts the cursor at the end of the last item and hits Enter,
producing a new item. "That's not what I want" he mutters, while changing the look
through Format->Paragraph to remove the indenting and the bullet.

 b)  between two procedures, Ed decides to add a warning. (Ordinarily in defence
documents, warnings occur at the start of a procedural list, so the user doesn't
flip a page and find that they're all of a sudden working on something potentially
dangerous.) Ed knows the conventions, but ignores them because "in this case, the
warning really only relates to one procedure, there are only two procedures in the
list, and the danger isn't great anyway". (Gimme three good reasons...) Ed saves the
file and advises the documentation team, makes himself a coffee and goes back to his
game of Freecell.

Regardless of whether this data is being converted to SGML or just to FrameMaker,
these two modifications can have serious ramifications. In the first case, if the
document isn't SGML, the paragraph will at least be mistagged, meaning that global
changes from within Frame based on the style name will result in visiably incorrect
data. If the document was being converted to SGML, it would be worse yet - the
formatting would disappear and the item element would be applied.

In the second scenario in a non-SGML situation, the data would be confusing to the
user, and in a situation where there is any danger (even though Ed rates it as low),
this is not acceptable. In SGML, if the incorrect style tag has been applied, the
change may go through as being valid, because it is not tagged as a warning element.
Otherwise, the documentation team will return the document to Ed and ask him to fix
it. "Fix it how?" asks Ed. "Make it legal" they tell him. "Legal in accordance with
what?" Ed asks. "Legal in accordance with the structure that we're insulating you
from, for your own good" they reply, patting Ed on the head. "I understand!" says
Ed, with the lights visably coming on, "you want me to mark up the documents in
accordance with a structure that you a) won't reveal the rules for, or b) provide an
application to assist me with".

> But if the company standard is MS-Word, the answer will be: No Way!

If the company standard is SGML, the answer will be "No Other Way!".

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

I don't know enough about this to be authoratative either, but I don't believe that
it's as complicated as you've outlined, especially for SGML documents - can someone
else jump in?

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

It will if it thinks (via the SGML Declaration) that it's importing SGML. If the
import structure matches the export structure, it would obviate the issues in your
previous point, wouldn't it?

> Perhaps I purposely overstated it when I said "demise", but it's not an
> absurd conclusion.

That is what I colloquially refer to as a "Danism" :-)

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

I don't believe that illustrating how the two products work together is likely to
lead people to using Frame. On the contrary, I think product differentiation is what
gets Frame into sites. What do you gain by being able to import all of the crud that
gets created in Word into Frame? You get the same crud in a different application.
Continuos round tripping such as you describe will result in more and more crud
accumulating up in your documents, until you get to the point where you find that
some headings aren't appearing in the TOC, or something equally sisnister. Frame
then looks bad and so do you, because you promoted it as an application capable of
handling global issues. Part of the reason that Frame is such a good tool is that it
is used by people who understand the importance of good documentation. I don't
believe for a second that these people can be replaced by a filter.

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

Word and FrameMaker serve different markets - that's why FrameMaker continues to
survive.

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

Those are the commercial realities that face any software company, but I'm inclined
to leave the significance of the juxtaposition of the two products up to the
experts. Don't forget, the advance of XML favours FrameMaker+SGML at the expense of
Word. Despite the promises from Microsoft, the lack of XML support in Office 2000 is
widely regarded as being bitterly disappointing to the XML community. Microsoft knew
what we wanted, but for whatever reason, couldn't deliver. There would have been
beer flowing the day that Adobe got their hands on the beta of Office 2000 - I'll
guarantee that. Microsoft may be able to wipe out FrameMaker(+SGML) in its own
market, but it will never eliminate it without matching it for features, otherwise
it would already have happened.

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

There are two issues with this - the first is that the quality of the tookit is not
a factor. The problem is with the users, and no software will fix that. The second
issue is with the structure that the toolkit will capture - if it requires/allows
configurability, then maintenance will be expensive. Also, it can really only
capture what a user has made something look like and what style tag has been
applied. If you're round tripping in an SGML loop, you lose recursion information
with every conversion to Word. Depending on the DTD, this may well be fatal.

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

I don't think I'd use the word "forced", but I do agree that there is a cost
associated with moving to a structured environment, and no person or organisation
will move to it unless they can see clear benefits. When they do require a
structured approach, I would advocate using tools that support structure, not a
collection of processes that attempt to emulate it. If they are unable to reconcile
the benefits with the cost, then they probably shouldn't bother with it.

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

It's hard enough to get through good projects cleanly - I'd think several times
before I took on a project where the specified objective was to "muddle through". I
wonder, would you give the same consideration to a filter that converted a document
of Word tables into a database? This is essentially the same as what you are
proposing. You might sell such a solution to managers, but you'd never get it past
the techies.


--
Regards,

Marcus Carr                      email:  mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein



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