Structured Frame s-l-o-w-l-y opening a document

[russ at weststreetconsulting.com]

Trevor,

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 formatted).

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.

Russ

------------------------------

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

Hi

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
by.

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 > myfile.fm'.

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?

Cheers
Trevor