New to the list, and asking for help

[Daniel Emory]

--- Pedro Pastor <pps at ua.es> wrote:
> Maybe the troubles I've found come from my
> inexperience developing structured applications in
FM, but I cannot fully understand the aim
> behind the (so called) "XML-roundtrip" editing.
==========================================
Assuming that the documentation you are creating and
updating/editing is accomplished by human beings, you
can avoid XML-roundtripping only by having your
writers create/modify tagged XML. If you expect to
have any semblance of a productive authoring
environment, you must "round-trip" the XML into some
sort of authoring product which provides the numerous
bells and whistles needed to hide XML internals from
your authors. Most XML editing produces are not
WYSIWYG, and thus in those editors authors see
something that is not a facsimile of what human
readers will see when they retrieve those documents. 

Structured FrameMaker is just as much an XML editor as
any of the other ones. It provides an automated way to
import XML instances into FrameMaker, preserving all
the XML internals, and at the end of an editing
session, it provides an automated way to export the
work product back into fully conformant tagged XML
output.

The extra feature of FrameMaker is that it avoids the
necessity of having to use the clunky and
difficult-to-implement XML tools used to accomplish
acceptable formatting and layout needed to make
documents that are highly readable and effective for
human users. That is, FrameMaker, in addition to being
a powerul way to create documents, can also serve as a
powerful print engine for delivering high-quality,
eminently readable, technical documents in paper or
PDF format. 
==============================================
> 1) I cannot understand how to clearly separate
> structure from presentation in FM. If EDD contains 
> structure and presentation
> information we are against the main principles of
> SGML/XML document
> design!!
=========================================
Gee, the idea behind FrameMaker is to have the best of
both worlds. Desktop publishing systems like
FrameMaker have highly sophisticated formatting and
layout capabilities. You can, however, completely
ignore presentation in an EDD simply by declaring that
all text will use a single paragraph style. If, on the
other hand, you decide to exploit Frame"s exquisite
presentation capabilities, you can export a structured
Frame document to XML or SGML, and none of that
formatting information gets exported, hence it in no
way violates the canons of XML or SGML.
 
The fact is that both SGML and XML provide a set of
clunky, insufficient and unwieldy tools for delivering
formatted output for printing or on-line display. The
FrameMaker EDD offers a far more robust and elegant
method for producing high-wuality presnetations.
======================================
> 2) It seems like there are two placeholders
> for storing presentation information: Templates and
EDD documents. This could be
> redundant, I mean, the same presentation definition
> data could be store
> on both places.
=======================================
Again you denigrate a powerful feature of Frame. The
EDD specifies the names of paragraph, character and
other types of formatting tags based on element
context. Templates are used to specify the formatting
details for each such tag. There are two advantages to
this. First, you can change the formatting (e.g.,
fonts, sizes, etc.) without disturbing the EDD.
Second, you can create multiple template versions for
the same EDD, allowing you to deliver differently
formatted documents which meet the requirements of
different types of users or different types of
documents created from the same EDD. Another feature
of the EDD is format change lists, which allow certain
parameters (e.g., indents, fonr size, autonumbering)
of a given format tag to be modified in different
structural contexts. 
===========================================
> 3)       In addition to this, Template document
> could have structure
> associated with it (via importing EDD document).
> Then we get just
> another way of associating structure to documents,
> apart from the DTD
> specification!!).
========================================
Wrong again. A DTD contains no formatting information.
You create an EDD. Then you import that EDD into an
empty FrameMaker document, and the EDD "seeds" the
empty document with all the EDD's structure rules as
well as all the formatting tags defined in the EDD.
Then the designer defines the parameters of each
EDD-defined format tag. If your production needs
require different presentations for different
customers or different types of documents (all created
from the same EDD), You create more than one
structured template for the same EDD, and design the
formatting of each version of the template to meet
specific formatting and layout requirements.

To create a new structured document, you select the
appropriate template file and apply it to a new
(empty)FrameMaker file. 
=========================================  
>  It seems to me that this roundtrip is  trying to
> match a mature legacy
> product (Structured FrameMaker) with the new
> emergent XML technologies,
> but it is not intended for XML authoring (as its
> main objective). At
> this point, (it seems)  it is easy to me to produce
> XML documentation
> (using whatever DTD I'd like) by means of more
> "developer-oriented" XML
> editors like XML_Spy or Oxygen together with
> XSLT+CSS style-sheets then
> all the burden of taming Structured FM for this
> purpose.
>  
> I'm sure I should have misunderstood something in
> this picture, and
> that's the reason why I ask for the help of the
> experienced FM users.
=========================================
FrameMaker, like other desktop publishing systems,
provides authors with a WYSIWYG presentation of the
information being created. There is no doubt that this
approach greatly enhances writer productivity and
effectiveness. FrameMaker's structure view, element
catalog and other structured authoring aids provide
additional productivity leverage.

As far as I'm concerned, technical documents output in
XML format should never see the light of day outside a
database unless it is being delivered to a non-human
user. By that I mean you must run the XML through some
sort of formatting engine to get something usable to a
human reader. The "standard" XML toolset used to
produce human-readable documents is pitifully weak and
difficult to use compared to what FrameMaker can
produce by importing XML instances into a FrameMaker
structured application, and, once again, the
comparative ease with which a FrameMaker application
can be developed further leverages the productivity of
a writing group.