🚀 go-pugleaf

In <1993Jan5.074304.1652@gmd.de> Tom Gordon, I3.KI 2665 writes:
>Has anyone had a chance to try FrameBuilder, the SGML version of FrameMaker,
>who would be willing to share their first impressions?
>

FrameBuilder was demonstrated at SGML '92 and I spent some time
looking at it and talking to the folks from Frame.  It was
difficult to judge how its SGML support really works, so I can't
comment on what features of SGML it actually supports, or how,
but I must say that the interface looked very good.  The mechanism
they have for working with structures seemed very well thought
out and intuitive.  It seems to hold some promise for being a
truly WYSIWYG SGML authoring system.  The Framemaker product
is already a very strong competitor in the WYSIWYG (non-SGML)
arena, so one could reasonably expect that function to carry
over.  The test will be how much of SGML is actually supported,
a question to which I don't know the answer.  Will it, for
example, manage marked sections and entity declarations for
you?  Will it automatically manage ID and IDREF attributes?
Does it support CONREF?  What parser does it use?   How
difficult is it to adapt to a particular DTD or set of
application-specific processing semantics?  How does it support
tables?  How is presentation style specified, in some non-SGML,
proprietary way or using an SGML style document like FOSI?

Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-543-7091
IBM Corporation
Research Triangle Park, NC 27709

In article <19930105.062726.39@almaden.ibm.com> drmacro@ralvm13.VNET.IBM.COM writes:
>In <1993Jan5.074304.1652@gmd.de> Tom Gordon, I3.KI 2665 writes:
>>Has anyone had a chance to try FrameBuilder, the SGML version of FrameMaker,
>>who would be willing to share their first impressions?

>FrameBuilder was demonstrated at SGML '92 and I spent some time
>looking at it and talking to the folks from Frame.  It was
>difficult to judge how its SGML support really works, so I can't
>comment on what features of SGML it actually supports, or how,
>but I must say that the interface looked very good.  The mechanism
>they have for working with structures seemed very well thought
>out and intuitive.  It seems to hold some promise for being a...

I've had several chances to examine FrameBuilder. I agree that the
interface is well-thought out, and that the notion of structure is very
well integrated into the new product. It should be easy for an experienced
FrameMaker user to go to FrameBuilder. The problem is that FrameBuilder (as
it was demonstrated to me) does not support SGML. FB only makes it possible
to create documents that have a predictable structure--it does not know zip
about SGML.

FB has no parser, and does not know what a DTD is. You cannot validate
documents written in FB within FB to see if they conform with a DTD, and
you cannot translate a DTD into a FB "structure". As I understand it, what
you would have to do is create a structure template in FB that conforms to
your desired DTD. Then, you will have to filter documents created by FB to
attach the SGML tags and filter out FB-specific junk, and you will have to
run the result through a parser to verify that it conforms to the DTD. (If
it doesn't, too bad.) To get an SGML document into FB, you will have to do
the reverse.

Thus, I think to say that FB "supports SGML" is to use the word "supports"
in a very elastic way. I would say that FB is "SGML friendly", in that it
allows for a structured document; but using FB in an SGML framework will
still require that you write (and use) filters and other tools that make
conversion to and from the SGML format possible. 

>is already a very strong competitor in the WYSIWYG (non-SGML)
>arena, so one could reasonably expect that function to carry
>over.  The test will be how much of SGML is actually supported,
>a question to which I don't know the answer.  

Nada. Zip.

>Will it, for
>example, manage marked sections and entity declarations for
>you?  

Nope.

>Will it automatically manage ID and IDREF attributes?

Hah.

>Does it support CONREF?  

Eh? Whazzat?

>What parser does it use?   

Parser? We don't need no steenkin' parser!

>How
>difficult is it to adapt to a particular DTD or set of
>application-specific processing semantics?  

Any decent programmer can do it for you...

>How does it support
>tables?  

Oh, it has tables. But then so does FrameMaker...

>How is presentation style specified, in some non-SGML,
>proprietary way or using an SGML style document like FOSI?

It's done just as you always specified presentation in FrameMaker: by means
of paragraph and character types.

Don't get me wrong: I _like_ FrameMaker as an authoring tool. I think it's
a fine product. However, I think that the claim that FrameBuilder
"supports" SGML is...how shall I say it...truth-challenged. 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             |      Die Welt ist alles, was Zerfall ist.     |
Peter Cash   |       (apologies to Ludwig Wittgenstein)      |cash@convex.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The description of FrameBuilder's "SGML support" by Peter Cash is a
major stunner, if it is accurate.  The Fall issue of <title>Frame
Focus</> had a lead article "Frame Joins Forces with Datalogics" which
said, among other things:

     FrameBuilder provides full, native support for Standard
     Generalized Markup Language (SGML), a widely adopted ISO
     standard for document interchange.

Nobody doubts that Datalogics does "real" SGML, I assume, but the
truth about (current, projected) FrameBuilder deserves to be
clarified immediately.

Assuming that Frame technical support personnel are tuned to this
channel: may we hear a direct and specific reply to the points
made in Peter Cash's recent posting?  If Frame tech support will
not reply, than can we hear from others who currrently have
FrameBuilder in hand, and who have studied the specifics of its
"SGML support."

I thought that "full, native support for SGML" would mean a true
SGML editor that would read any SGML DTD + document instance and
get right to work.

Robin Cover

-------------------------------------------------------------------------
Robin Cover              BITNET:   zrcc1001@smuvm1  ("one-zero-zero-one")
6634 Sarah Drive         Internet: robin@utafll.uta.edu  ("uta-ef-el-el")
Dallas, TX  75236  USA   Internet: zrcc1001@vm.cis.smu.edu
Tel: (1 214) 296-1783    Internet: robin@ling.uta.edu
FAX: (1 214) 709-2433    Internet: robin@txsil.sil.org
=========================================================================