This is my experience with long XML files as well.  I'm pretty sure it is 
caused by the application of formatting by the EDD, which takes some time when 
it has to evaluate formatting rules element-by-element for 500 pages.  It 
doesn't need to do this for a .FM file, because the formatting metadata is 
already assigned in the binary.  So, I think it's just the nature of the tool, 
and your complaint is quite reasonable.  At the FrameMaker Chautauqua, I 
mentioned this problem to the development manager, and have subsequently made 
it a personal rule-of-thumb to keep all XML files less than 100 pages (as 

I don't know what the real answer might be, but I'm confident that this 
handicap (among others) will have to change if FrameMaker wants to stay a 
serious contender in the XML space.



Message: 4
Date: Wed, 21 Feb 2007 01:49:36 +1300
From: "Trevor Nicholls" <>
Subject: Structured Frame s-l-o-w-l-y opening a document
To: <framers at>
Message-ID: <000501c754ed$944460c0$0401010a at TREVOR>
Content-Type: text/plain; charset="us-ascii"


I was interested to read the recent discussions about (why/why not) use
structured Framemaker. I started with Framemaker at version 7.2, have never
known anything but structured authoring, and adopting unstructured authoring
doesn't appeal to me as a positive move in any way. However, that's by the

I have an application which uses structured Frame as its document editor.
The documents themselves are stored as XML files and, apart from one
bottleneck, the application works satisfactorily. That bottleneck is the
time taken by Frame to open an XML document.

Illustrative timings:
On a 1.7GHz/1Gb machine: 85 seconds from 'File > Open > myfile.xml' to being
presented with the document in Framemaker.
On a 3.5GHz/2Gb machine: 60 seconds.

Framemaker runs an XSL step which tweaks the XML for Frame (wrapping graphic
elements inside <wrapper>, adjusting table contents, pulling included
subfiles inline, etc.). Xalan runs this stylesheet outside of Frame in less
than 4 seconds. (Just in case this isn't widely known, Frame uses a version
of Xalan as its XSL engine.)

If I load the file, clear the structured application, and save the full
document as a .FM file, then re-start Frame, I can start editing the
document within 5 seconds of entering 'File > Open >'.

So the document load time breaks down into:
4 seconds to run the initial XSL
76 seconds for Frame to put the temporary XML file into native FM form
5 seconds to load the FM document

Although "myfile.xml" is small, pulling in all the included subdocuments
produces a document of some 500 pages or so. I'm not expecting the file load
process to be instantaneous, but a minute and a half is unacceptable. 

What options do I have, if any, for reducing the 76 second overhead?


Reply via email to