Re: How good is FrameMaker XML export? Tools?

[jeremy@xxxxxxxxx (Jeremy H. Griffith)]

On Thu, 27 Sep 2001 12:45:43 -0700, Dan Emory <danemory@primenet.com> 
wrote:

>There is a huge difference between FrameMaker and FM+SGML in exporting 
>XML.. In FrameMaker, tags in unstructured documents must be mapped 
>corresponding elements. The XML output should be well-formed, but it cannot 
>be made to conform to an XML DTD. Moreover, since unstructured documents 
>have no way of storing metadata, metadata, in the form of element 
>attributes cannot be exported.

Quite right, when you speak only of *native* FM XML export.
However, if you use Mif2Go to make XML, many of these issues
go away.  You still have to map from format names to element
names, but you also get to specify attributes, and can use
macros freely before and after elements (and elsewhere).

Since FM's document model is essentially "flat", what you
would get if you only mapped names is one root element
(which you specify in the .ini file), containing an element
for every pargraph.  The para elemnts, in turn, can contain
elements for each char format used in them.  This *could*
conform to a DTD, but it would be a very simple DTD.

If you want to organize the para elements into higher-level
sections, you need to specify the code to use at the start
and end of each section.  There are several ways you can do
that; your choice of method depends on the existing and the
desired structures.  You can:
  - use a CodeBefore macro for a particular para format that
always starts the section.
  - use a CodeAfter macro for the para format that ends it
  - use a marker containing the code or a macro reference
  - use a dedicated para format and put the code directly in
the FM doc, probably conditionalized.

For the first two methods, you may need to rename the para
formats at the start and end of the section so that they
are unique to their usage, much as people rename Heading1
to be Heading1 First, Heading1 Top of Page, etc.  The other
two methods avoid such renaming, but require an edit in the
FM doc at each point where such additions are needed.

Another possibility is to take the "raw" XML (which is
always well-formed) and process it with XSLT to produce
pretty much any structure you want.  This has two problems.
XSLT processors are not fast, especially on very large
docs; most are in Java, but even the C++ implementations
take longer than you may find tolerable in production.
Second, designing the XSLT template to add the structure
may be a guru-level task; again, it all depends on where
you are and where you want to go.

It's true that FM+SGML offers more capability, but it comes
at a price.  Not just the added license cost from Adobe,
but the lengthy training and study one is likely to need
to use it properly unless your name is Berners-Lee, Clark,
Emory, or Price (in alphabetical order, and I'm not sure
about that first one... ;-).  FM+SGML *may* be the best
answer, but in these tough economic times a little $295
plugin that also does lots of other handy things, like
Mif2Go, may prove to be a better deal.  Check it out.

-- Jeremy H. Griffith, at Omni Systems Inc.
  (jeremy@omsys.com)  http://www.omsys.com/

** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **