Re: [FrameSGML] XML import/export to/from FM+SGML

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 09:34 PM 3/30/00 -0500, Rick Quatro wrote:
>I am on the fringes of the SGML world, with most of my experience coming
>from writing FrameMaker EDDs and templates. But, I would like to add some
>thoughts on this issue. It seems to me that direct XML export from
>FrameMaker is going to be on par with their native HTML export--not very
>good. What is probably going to be required is a solid SGML DTD with
>read/write rules, etc. for export from FrameMaker+SGML. Then you would use
>OmniMark to convert your SGML to XML with links preserved, etc.
================================================================
In all my comments below, I'm talking about XML export from structured
FM+SGML documents.
++++++++++++++++++++++++++++++++++++++++++
XSL transformations are supposed to do the same thing as OmniMark (i.e.,
move data from one XML representation to another). The real problem,
however, is to get cross-references and hypertext markers in FM+SGML
converted on export to something at least approximating the proper
representation in XML (or even HTML). Right now, it doesn't seem possible,
but perhaps there's a way to crack it. The problem pertains to both internal
and external links/cross-references.
++++++++++++++++++++++++++++++++++++++++++
>I am an OmniMark newbie and am very impressed so far. I had written a
>FrameScript script to import XML into FrameMaker, find the tags, and apply
>formatting based on a rules table (similar to the table you use to add
>structure to an unstructured document). It was very difficult to parse
>through the tags, correctly apply the formats, and then delete the tags. It
>worked, but it was slow--6,000 lines took almost 2 hours on 200 mz Pentium.
>I am sure some speed would be gained with a compiled API client.
==================================================================
The problem with formatting is not restricted to the .CSS file. The
XMLcss.dll plug-in for V5.5.6 (downloadable from the Adobe web site) is
supposed to be able to produce a .css file that derives formatting
information from all EDD format rules, including those where formatting
varies according to element context and attribute values. If it worked
right, it would be enormously advantageous to be able to almost exactly
replicate the formatting in the FM+SGML document, avoiding all the hassle
involved in developing templates in WWP, for example. However, I've noticed
some formatting anomalies.

There are also anomalies in the .xml file. One nifty thing about the XML
export is that autonumbers are preserved on export in the XML instance, not
the .css file. These autonumbers, derived from the format rules in the EDD,
in some cases specify an en-space at the end of the autonumber. However, the
en-space character appears to be exported as the Unicode character for a
bullet, because a bullet, followed by a space are what appear in place of
the en-space when the XML instance is opened in IE5. I do not think this is
an IE5 problem.
+++++++++++++++++++++++++++++++++++++++++++++++++++
     ====================
     | Nullius in Verba |
     ====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
   majordomo@omsys.com with "subscribe framers" (no quotes) in the body.


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