FM+SGML vs. Arbor Text....yeah, but can it do THIS?

["Jason Aiken" <jason.aiken@xxxxxxxxxxxxx>]

Greetings Framers of the SGML world,

This message is specifically directed toward SGML power users out
there. Please offer your opinion on any or all of the issues raised
below. Offline responses will be summarized to each list unless
confidentiality is requested.

In March of this year, I posted a query to compare Arbor Text and
FM+SGML. Several users responded with very helpful information. In fact,
the information acquired here has had a profound impact on our decision
making process. Special thanks to both lists and those who responded. I
also would like to extend thanks to those attendees of the FrameUsers
Conference who took the time to share their opinions on this subject.
Surely there is a future InFrame article to come out of all this...but
that's further down the road.

During our research, several criticisms of FM+SGML have forced us to
consider other authoring tools. Please respond on the following:

1. SGML round-tripping: Can one go from FM+SGML to SGML to FM+SGML
again without corrupting any data?

It is imperative that we get 100% consistency during each
edit/conversion cycle in order to work properly with translation memory
software. I understand FM+SGML creates SGML compliant data, but if you
ran a "diff" on the FM+SGML file before and after parsing to SGML and
back, is it always the same? Is data such as variables or conditional
text ever lost?

2. Is it true that FM+SGML cannot create, import, export or preserve
SUBDOCS? What about marked sections?

3. Is it true that FM+SGML cannot be used for a component based SGML
repository?

Dan Emory, a renown FM+SGML guru, criticizes FM+SGML for its failure to
create FM+SGML text fragments as exportable SGML entities---"if such a
fragment does not begin with an element that is valid at the highest
level, it is not exportable." Is it impossible to create, import,
export, and preserve SGML text entities (i.e. chunks) in FM+SGML?

4. Case studies: is anyone in the world using FM+SGML with a
controlled, component-based SGML repository to publish content in
multiple output formats and multiple languages?

5. Performance: on a 400 page manual with scores of graphics and
somewhat complex components, is there a serious performance issue
parsing to SGML from FM+SGML (does it take seconds, minutes, hours...)?
Conversely, are there major performance concerns when compiling SGML
chunks into a pretty 400 page book using Xyvision or Adept Editor?

6. Implementation: is it cheaper, faster and easier to implement an
FM+SGML solution with complex DTD/EDD (and possibly FDK) development
than (for example) an Arbor Text, Xyvision, DTD/FOSI combination?

BACKGROUND: We are developing a documentation factory. We must automate
every aspect of publishing from authoring to translation to final output
in such a way that allows scaling and guarantees 100% compliance with a
controlled, component-based SGML repository in at least a dozen
languages. If we can't make FM+SGML work, without exorbitant costs,
delays or hassle, for items 1-3 listed above 100% of the time, we will
have to abandon FrameMaker.

Respectfully,

Jason Aiken
Frame Templar

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