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" <tre...@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