NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/text/sgml/1293

Internet Message Format | 1993-01-11 | 3.9 KB

Path: sparky!uunet!vnet.ibm.com
From: [e-mail] (Wayne L. Wohler)
Message-ID: <[e-mail]>
Date: Mon, 11 Jan 93 17:21:48 MST
Newsgroups: comp.text.sgml
Subject: FrameBuilder
Disclaimer: This posting represents the poster's views, not those of IBM
News-Software: Usenet 3.1
Lines: 64

<MoreDisclaimer>I have seen two demos and talked for 1 1/2 hours with
Joe Schneider (their Unix product VP, apologies to you Joe if I got that
wrong) about FrameBuilder.  I have had very little opportunity to pound
the keys with it.  I'm giving my own opinions about FrameBuilder, not
IBM's (or Frame's, for that matter).  I may have some details wrong but
the bits and bytes aren't my point anyway</>

My understanding of the FrameBuilder product is that Frame believes
there is value in a structured, hierarchical view of document data.
They recognize that SGML is an important standard for interchanging this
class of data.  They set out to build a structured document editor, not
just an SGML editor.

I am not surprised that they have retained the concept of an internal
data structure representing a document.  I am also not surprised that
they did not incorporate an SGML parser in the editor itself.  Editors
are interactive and fairly random in their access of data, SGML parsers
are quite sequential.  It is a common tradeoff that is not antithetical
to happy coexistence with SGML.  The export routine must be fairly
sophisticated in this environment to prevent inadvertent markup
problems, I acknowledge.

The arm's length philosophy of handling SGML seems also to have led them
to not support attributes per se.  They assume a translation during SGML
import into the editor will convert attributes to the editor semantics.
Attributes which do not have such a representation will have to be
retained using other means within the document.  With this concept the
author doesn't enter attributes, they change editor or component
settings.  The export routine makes the appropriate conversion.  ID/IDREF
is an good example of this type of handling.  My understanding is that
marked sections are handled in similar fashion.

It is clear from their handling of attributes, application designers
must do a significant amount of work to support their applications.  I
am surprised that an automatic tool for converting DTDs to Frame's
structure definition language is not part of the product.  Perhaps this
was considered a small part of the job.  In addition to attributes,
markup minimization, comments and other parts of the SGML language may
or may not be retained, depending on the SGML parser being used and the
sophistication of the import and export.

It is unfortunate that there is so much effort is involved in developing
a new application with FrameBuilder.  Maybe that is why they bought
Datalogics as their services arm, to help their customers build the aps.
It is clear that a better application interface for supporting SGML
applications under FrameBuilder is needed.  Presumably, its clear to
Frame too.  On the other hand, from what I've seen and heard, it isn't
that SGML semantics can't be supported, its that they haven't been
supported in a general way and at least for now, the application
designer must architect and implement the support him/herself.

Given the choice, I would want my users to use an editor that supports
SGML more robustly.  If forced to make a choice, I would work pretty
hard to get my users to use this product with whatever application
support I could build for it in preference to FrameMaker or any of the
current word processors.  While they did not meet my expectations and
fond hopes, I look at the glass as being half full, not half empty.

Wayne L. Wohler                   Internet:  [e-mail]
Dept G82/910M                     IBMMAIL:   USIB29WX@IBMMAIL
Publishing Solutions Development             Phone: [phone]
IBM Corporation
Boulder, Colorado  80301-9191