🚀 go-pugleaf

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