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

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

Here's the folks who have responded so far. My original list of six
questions is at the very end. Thanks to all those who responded with
such insightful opinions and detailed analysis. The Frame Templar thank
you and will modify their weekend rituals to chant acknowledgment to all
helpful contributors.**

### "Steve Schwedland" <steve@noonetime.com> ####################

I'm still awaiting Steve's PC (ahem) response to my question. Steve,
please send your response to the list.
I could paraphrase the good stuff here, but I won't do it justice. To
briefly summarize, he mentioned that Astoria could likely handle the
situation with some custom API work and brought up a tool called Lingua
for localization. He also said that FM+SGML is a great publishing engine
and would work in combination with other tools.

############################################################

### "Kevin Brown" <kbrown01@worldnet.att.net> #####################

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

Absolutely untrue.  Chrystal Software has many installations of our
SGML
component database management solution integrated to FM+SGML using our
software bridge.   It provides component-level management and
component-level editing from within 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?

I am sure we can provide you with contact information, but off-list. 
Send
me an email and I will get you in-touch with representatives.

############################################################

### "Vic Fragnito" <Vic.fragnito@alliedsignal.com>
#####################

To get round trip FULLY COMPLIANT SGML is difficult with both FM and
Adept.
Adept is more native in its handling of SGML and has a greater
propensity to
produce effective round trip SGML.  FM requires addition of anchor
elements
for the display of graphics whereas Adept does not.  This does posse a
unique concern and requires after the fact programming or an in line
FDK
application.  Adept handles entity selection on a pull down whereas FM
requires creation of a palette.  I am a FM advocate but it is a
challenge.

As far as paper is concerned, both the FOSI and EDD are equally
complex.
They require specific skills and capabilities and it is not easy.  If
your
DTD does not exactly match the order of presentation, both products
suffer
and require custom programming.  The same is true of Xyvision.  FM is
more
of a WYSIWYG tool whereas Adept and Xyvision are in the background and
require expenditure of funds for the developer environment.

Check into a product by Advent Technologies, call 3B2.  www.3B2.com 
<http://WWW.3B2.com> 

This tool allows WYSIWYG batch rule based output and allows
manipulation of
text and graphics without affecting the SGML instance.  It is the best,
my
opinion, tool to get an SGML document out to presentation and assure
round
trip SGML.  It corrects the deficiencies in both FM and Adept.

Component SGML management is a problem to all SGML systems.  Most
reuse
models do not address or handle ID/IREFS for reuse.  Chrystal Software
(Astoria Object based DB) is the best for its reuse model but it is
still
deficient in the reuse model by component.

#####################################################

### "Dan Emory" <danemory@primenet.com> #################

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

###########################################################

###"Patti Nolan" <tsisink@earthlink.net> ######### Part one
###########

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

When you noted Xyvision I felt I needed to respond. I've been
typesetting for 27 years, I've worked on several main frames; Penta,
Xyvision, Miles. A year and a half ago my company decided to combine
its
editorial services, The Smart Editor (SES)  and FrameMaker+SGML 5.5.6.
I
found the major differences to be:
1) Xyvision translation tables inable you to avoid most if not all
programming needs that you will with Frame require.
2) With Xyvision you can rearrange text, search on text content, with
Frame it will require programming intervention.
3) Speed and memory: Xyvision there is no problem, with Frame there is
a
memory leak, so you do have to be careful with how large your files
are
pior to composition.

I personally prefer Xyvision (old dogs ...), however, we have found
that
there is nothing that we can't do with FrameMaker+SGML as long as
there
is programming intervention. As for cost, FrameMaker+SGML is by far a
better buy. But if you have a great deal of graphics (EPS), and your
final output is a print product then, you will probably want to have
Frame on a Mac platform. We have it on NT 4. Xyvision does support
SGML
with FrameMaker which would give you the best of both worlds. You
should
probably look into that combination.

I hope this has helped.

Regards,
Patti
tsisink@earthlink.net 

PS I really like working with the EDD

#########################################################

###"Patti Nolan" <tsisink@earthlink.net> ######### Part two #########

There are two other items that may be an issue for your company.

1) Tabular: If you have a lot of  large tables that need to break
automatically to the next page Frame does not do that automatically it
will require programming intervention, Xyvision does. If your page
layout (template) is 1 column and your tables could be 2-5 columns (not
within the table, but should break evenly into columns) with Xyvision
it's a simple macro <pc;2> could be defined to break the table into 2
equal colmns on the page. With Frame I don't believe that it is that
easy, but look to Adobe about tabular before committing to Frame+SGML.

2) Fonts: If you are planning on putting Frame+SGML on an NT platform
you will encounter problems (and need programming intervention) with
fonts if you have the following situation: Lets say your using Helvetica
Bold and Times both your document uses a lot of accented characters that
do not esist on either font, so you've created two new fonts for this
problem. Lets say your new fonts have an acute over a lowercase a (a).
You now have 4 fonts Helvetica Bold, Helvetica Bold Accent, Times, Times
accent.

    <Head>Example: <Para1> Both of these require an accent over the
lowercase a in Example and the a in an.</Para1></Head>

In Frame what you will have to do is for your Accent font create a
variable in your template, such as aacute & aacute (for reg Helv. Bold &
Times) HBaacute for lowercase, HBAacute for uppercase, and the same for
Times, Taacute and TAacute. My assumption is that your new fonts do not
have the same hex positions for an a with acute. Then programming will
have to write a dll that will test to see if  the variable <aacute> or
<Aacute> is in <Head>, if in head change to <HBaacute> or <HBAacute>

If you're on a Mac with Frame+SGML fonts should not be a problem. I
know that my example might be a bit confusing, so feel free to call me.

All of the projects that I do on Frame are completely automatic from
start to finish, which does require programming. Any of the projects
that I do on Xyvision can be completely automatic from start to finish
with a simple tag line at the beginning of the ASCII file.

On all of the items I've listed on both emails I want you to understand
that I really do like working with Frame+SGML and if what your needs are
to maintain a database than I feel you are looking at the right software
for the price.

#############################################################

### "Jason Aiken" <jason.aiken@medtronic.com> #### original query
######

Several criticisms of FM+SGML have forced my department 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?

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 natively be used for a component
based SGML
repository?

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?

** See "Newcastle: A Beverage Fit for the Frame Templar" in this
month's edition of The Templar's Travel Journal, published in Hartford,
Connecticut by C'thulu Lives! Press.

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