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

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 12:02 PM 11/10/99 -0600, Jason Aiken wrote:
>---------------------------------Snip
>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?
==================================================================
Yes, if you design the entire system correctly. By "system" I mean the
EDD/DTD, the import/export application, and the SGML database repository. If
you are designing your own DTD/EDD, it can be done. If you're stuck with an
existing EDD that's difficult (e.g., MIL-M-38784), you're likely to have
problems that can only be resolved with costly FDK development
=======================================================
>
>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?
==============================================================
Have you considered using TRADOS S-Tagger for translations? I've
successfully round-tripped FM+SGML structured docs in MIF format through
S-Tagger, eliminating the need to export to SGML for translation. However,
for many languages, there are problems with misconversion of certain
translated characters. This is where Unicode would help. No one seems to
know whether the next release of FM+SGML will fully implement Unicode.
Without Unicode, the most basic requirement to make translation work is to
use the same font for the printed output that was used for doing the
translation. Since most translation houses use Word 2000, that means
TrueType fonts. Also, there are 5 locked code points (i.e., ANSI numbers
that are unavailable) in FM+SGML, and these code points are needed in some
central european and cyrillic languages. There's no workaround. Xyvision has
no locked code points, and should (if not already then shortly) be
Unicode-compliant. For that reason, Xyvision, not FM+SGML may be your best
print engine.

If I were you, I would rule out any DTP/word processor/print engine that
will not be fully Unicode compliant. Unless you can get a firm commitment
from Adobe that the next FM+SGML release will be Unicode-compliant, I would
advise you to remove FM+SGML from consideration.
===================================================================
>
>2. Is it true that FM+SGML cannot create, import, export or preserve
>SUBDOCS? What about marked sections?
===================================================
Yes, those limitations still exist.
========================================================
>
>3. Is it true that FM+SGML cannot be used for a component based SGML
>repository?
================================================================
False! Chrystal Astoria has a bridge to FM+SGML, and I have seen it used
successrully with FM+SGML as a component-based SGML database 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?
====================================================================
I should modify that statement somewhat. In order to export individual text
insets as entities, each text inset source must be in a separately named
flow within an FM+SGML file, and must be wrapped in an element named
SGMLFragment. This element must be added to your EDD, but not to your DTD.
In the EDD, the SGMLFragment element must be defined as valid at the highest
level, with a general rule of <ANY>. When you export each individual text
inset, FM+SGML writes it out as a text entity (without an internal DTD
subset) with the filename you specify. Then, in the DTD, you must have an
entity declaration for each such text entity of the form:

        <!ENTITY entname SDATA "[SOI]" >
Where the bracketed SOI defines an indirect SOI (Storage Object Identifier)
whose "lookup location" is specified in the read/write rules and/or in an
entity catalog.

Now, you can you insert entity references to these text entities in your
SGML documents.

However, if you are creating/editing your docs in FM+SGML and then exporting
them to SGML for repository storage, you want to import individual FM+SGML
text insets by reference into various places in your FM+SGML documents.
Consequently, when you update the text inset itself, all documents that use
the text inset will be updated. But, in order to replace those text insets
within your documents with entity references when those documents are
exported, you must create a read/write rule for each such text entity,
having the following form:

        entity "SOI"{
                is fm text inset "filename"
        in body (or reference)flow "flowname";
        }
Where:
"SOI" is the same name (in quotes) that appears in the bracketed SOI in the
corresponding SGML entity declaration described previously.

"filename" is the FM+SGML document file that contains the text inset

"flowname" is the name of the text flow within the document file containing
the text inset.

You should not include a directory path for the filename in these read/write
rules. Instead, specify the directory locations of files containing text
insets as entity search paths in the SGML application definition.

Now, the problem with this approach is that, on export of a document
containing imported-by-reference text insets, FM+SGML writes an entity
reference for each instance of one. Then, when you re-import the SGML
document instance into FM+SGML, the entity references are replaced with the
original FM+SGML text insets, not the SGML text entities that you exported
separately as described above. So, if the text inset was updated in FM+SGML
after the last time the text inset was exported to SGML as a text entity, or
if the SGML text entity was edited in an SGML text editor, then the text
inset in FM+SGML and the corresponding text entity (stored in the SGML
repository) will not be the same.

There are other problems with text insets, including:

a. If a text inset contains variables, graphics, or other components that
are replaced by entity references on export to SGML as a text entity, the
DTD must contain declarations for all such entities, because a text entity
has no internal DTD subset where these entities can be declared.

b. Cross-references to or from text insets can create some nasty problems.
========================================================================

>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?
====================================================
I would think so. You should check with Chrystal.
======================================================
>
>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?
====================================================================
There's no substitute for real-world testing, using documents that are
typical in size and content.
========================================================================
>
>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?
====================================================================
Obviously, with an SGML text editor plus Xyvision, you don't have to worry
about developing an EDD or an SGML import/export application, thus these
costs are unique to FM+SGML, and they can be considerable. These added costs
may (at least partially) be offset by the (arguably superior) way to define
formatting in the EDD and the FrameMaker template. Thus, if SGML docs are
always imported into FM+SGML for formatting, you eliminate the
Xyvision/FOSI/DSSL development costs.
=====================================================================
>
>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.
===============================================================
You've got a tough decision to make. You first must define when and why a
cost becomes "exorbitant". High one-time development costs may not be
exorbtant if they yield a high Return on Investment (ROI) because of large
reductions in labor costs, and/or improvements in the management of information.
===============================================================
     ====================
     | 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.   **