Re: Frame+SGML vs. Arbor Text

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 03:16 PM 3/25/99 -0600, Jason Aiken wrote:
>Greetings Framers,
>
>We've heard a lot about the Frame vs. Word debate, but I'd be interested
>in hearing a debate about what seems to be the next level of argument
>--- Frame+SGML vs. Arbor Text.
======================================================================
I'm not familiar enough with the Arbor Text product to identify its
advantages and disadvantages, but I can describe what I believe are the
advantages and disadvantages of FM+SGML.
----------------------------------------------------------------
A. Main Advantages of FM+SGML as an authoring tool:
1. By virtue of context-sensitive format rules in the Element Definition
Document (EDD) you get:
        a. WYSIWYG authoring
        b. Fully formatted, DTP-quality printed output without having to
           develop a FOSI, DSSL, or XSL stylesheets

2. Element catalog indicates validity of all possible elements that can be
inserted at the current insertion point.

3. Element Merge/Split/Unwrap/Wrap/Change capabilities are excellent.

4. Interactive structure view facilitates text editing, editing/viewing of
attribute values, insertion point positioning, navigation, etc.

5. Show Element Context utility displays the hierarchical context of any
selected element, along with the format rules for that element. Any format
tag appearing in the element's format rules can be selected so that you can
examine the complete formatting details for the tag in the applicable
designer dialog.

6. Document Validation Tool is excellent. Finds all instances of invalid or
incomplete structures, as well as attributes having invalid values or
missing values that are required, highlights the offending element in the
structure view, and descrbes the nature of the problem.

7. You can leave required elements out (adding them later), and successfully
save is as an FM+SGML doc.

8. Parses SGML document instances against its DTD, and produces an error log
describing each
anomaly.

9. Built-in structure generator for converting unstructured FM docs to
structured docs, however, developing a structure rules table for this
untility is difficult, and the results are usually problematic.
---------------------------------------------------------------
B. Disadvantages of FM+SGML as an authoring tool:
1. Authors have no control over, or knowlege of, the names that are assigned to
entities (e.g., graphics, equations, text entities). In the case of native
graphics, equations and multi-faceted graphics, even their exported
filenames are unknown to the author. This is because the entity and file
naming conventions are established by the import/export read/write rules. In
the case of native graphics and equations, authors have no control over the
graphic format in which they are written out on export to SGML, because,
once again, this is determined by the import/export read/write rules.

2. Authors cannot create FM+SGML text fragments that are exportable as SGML
text entities. If such a fragment does not begin with an element that is
valid at the highest level, it is not exportable. If the fragment begins
with an element that is valid at the highest level, FM+SGML exports it as an
SGML document instance with an internal DTD subset, making it unusable as an
SGML text entity. Consequently, although an FM+SGML structured doc can
contain such fragments, imported by reference as text insets, that can (by
means of read/write rules) be exported as entity references, there is no way
in FM+SGML to create and export the referenced SGML text entities.
----------------------------------------------------------------
C. Advantages of FM+SGML in importing/exporting SGML/XML

None
----------------------------------------------------------------
D. Disadvantages of FM+SGML in importing/exporting SGML/XML
1. See also items B1 and B2 above.

2. Development of a complete SGML import/export application for a complex
DTD/EDD is often a lengthy and costly process, usually requiring considerable
API development with the FDK.

3. FM+SGML's representation of graphics and equations by means of a set of
attributes may not conform to the representation of these entities in an
existing DTD. In that event, it may not be possible to successfully import
or export those entities.

4. For tables, FM+SGML only supports the CALS table model.

5. No tools are provided in FM+SGML for developing a screen FOSI, DSSL, or
XSL stylesheet to permit on-line viewing of SGML/XML document instances
produced by FM+SGML.

6. FM+SGML cannot create, import, or export SUBDOCS, nor can it preserve on
import, or successfully export, marked sections.

7. FM+SGML has only limited capability to handle SGML processing
instructions (PIs) on import or export.

8. An FM+SGML book file (required for exporting a set of FM+SGML files as a
single SGML document) can have only one level of documents, whereas SGML
documents can have more than one level of nesting. On export to SGML,
FM+SGML exports each file in the book as an external SGML text entity.

9. When importing an SGML document, FM+SGML cannot subdivide it into SGML
documents in a book, unless the SGML document contains special
(FM+SGML-unique) processing instructions.

10. FM+SGML cannot successfully export or import cross-references to
documents that are external to a book, or, in the case of an individual
FM+SGML file, any external cross-references.

11. FM+SGML is currently incapable of properly importing or exporting
well-formed XML containing Resource Description Frameworks (RDF), and
resources (e.g., graphics, other documents) identified by means of Universal
Resource Identifiers (URIs). The export capability provided in version 5.5.6
is nothing but a variation on V5.5's HTML export capability, requiring the
mapping of paragraph tags (not elements). If the structure is complex, this
mapping
operation can be very difficult, if not impossible.

12. FM+SGML does not implement the XLink standard for XML links.

13. FM+SGML does not currently implement new language options (e.g.,
musical, mathematical, and chemical notation) that are possible in XML.   

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