What do you mean by xml:base mangling ?
Did the message "Too many nested apply-templates calls" disappear and the
Document root and attributes: <sect3 id="foo" xmlns:xi="&w3XInclude;" xml:base=""> Note the xml:base="" The following is the html source fragment from a 2 level xinclude (this document xinclude'd from an xinclude'd document ): src="file:/home/foo/docbook/foo/bar/file:/home/foo/docbook/foo/bar/figures/checklist.gif" Each subsequent xinclude nesting prefixes a source path ( file:/home/foo/docbook/foo/bar/ ) to the image source path So a 4 level xinclude nesting would produce: src="file:/home/foo/docbook/foo/bar/file:/home/foo/docbook/foo/bar/file:/home/foo/docbook/foo/bar/file:/home/foo/docbook/foo/bar/figures/checklist.gif" However, disabling or unchecking Preferences | XML | XML Parser Options | Base URI Fixup results in the following: src="figures/checklist.gif" This image source path is now correct Note this issue and resolution occurs in any XSLT ( html, pdf, rtf ); the user-selectable Base URI Fixup is new to v6.1; previous versions would appear to default (internally) to no Base URI Fixup. transformation started working> just by modifying the oxygen.sh startup params Yes
What was insufficient: heap size or stack size ?
Don't know. However, would suggest that oXygen QA always utilize a heavily nested (at least 5 levels of xinclude's with most docbook elements on each nested xinclude document ) xinclude test case(s) for every release build. This is most important as many of us now utilize nested xincludes extensively. Raymond