Copy link to clipboard
Copied
I am migrating a structured Frame application from FrameMaker 8 to FrameMaker 2019. Several months ago I did a trial migration to Frame 2017 and the open-edit-save roundtrip for a single document worked fine. Now I am doing the job for real with Frame 2019 (times move on).
Unfortunately when I attempt to open my sample XML document for editing the pre-processor stylesheet generates an error. This ran without problems in Frame 2017 (and of course the stylesheet runs perfectly outside of Frame).
The pre-processor stylesheet is XSL 1.0 so could run in any XSL processor; the post-processor stylesheet is XSL 2.0 so requires Saxon. Hence in my structured apps document definitions I have included
Template: $STRUCTDIR\xml\helpcenter\app\template.fm
Read/write rules: $STRUCTDIR\xml\helpcenter\app\rules
XSLT Preferences:
Preprocessing:
Stylesheet: $STRUCTDIR\xml\helpcenter\app\hcxml2fm.xsl
Postprocessing:
XSLT Processor: SAXON
Stylesheet: $STRUCTDIR\xml\helpcenter\app\hcfm2xml.xsl
The error I am getting on document open is this:
XSL Processor Messages (Processor: SAXON)
Error reported by XML parser processing file:/C:/Program%20Files/Adobe/Adobe%20FrameMaker%202019/structure/xml/helpcenter/app/hcstrip.xsl:
FWK005 parse may not be called while parsing.
net.sf.saxon.s9api.SaxonApiException: Error reported by XML parser processing file:/C:/Program%20Files/Adobe/Adobe%20FrameMaker%202019/structure/xml/helpcenter/app/hcstrip.xsl:
FWK005 parse may not be called while parsing.
Transformation Aborted.
The hcstrip.xsl stylesheet is included by the hcxml2fm.xsl stylesheet and there's nothing unusual about it. As I say, this identical setup worked in FrameMaker 2017.
Just for completeness, hcstrip.xsl contains this:
<?xmlversion="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:strip-space elements="included document section content
table th tb tf tr
list ol li inlist"
/>
</xsl:stylesheet>
Anyone got any ideas why this isn't loading in FM2019?
Cheers
T
Copy link to clipboard
Copied
Trevor, I believe this is due to a processing change between versions of Saxon. FM2019 includes a more recent version of the Saxon EE processor (9.8.0.7) compared to the Saxon HE (9.3.0.5) that was built into FM2017.
I found a relevant article on the Saxon forum here: Potentially undocumented change in XML parsing behaviour between Saxon 9.5.1 and Saxon 9.6 - Saxon -...
It would appear the problem is caused by changes made to enable XSLT 3.0 support. I've not had time to work out how to avoid this problem yet - I'll think on it.
Ian
Copy link to clipboard
Copied
So would I be right in thinking that if I put all imported and included stylesheets inline so that Frame used one monolithic stylesheet, this should avoid the problem?
I don't want to have to do that but at least it's doable.
cheers
T
Copy link to clipboard
Copied
I've spent a bit of time building monolithic stylesheets and verifying that the various template priorities reflected the import precedence correctly. So I've got to the point where simple XML loads and saves correctly. We're even roundtripping. EXCEPT...
There's still one big problem, which is cross-references to other XML documents. Our post-processor stylesheet looks up the target XML file via document(srcfile)/Xpath/to/referenced/item
and populates the cross-reference element with the clickable text. Again, this stylesheet works correctly when run outside of FrameMaker. Inside Frame it throws an exception with the same "FWK005 parse may not be called while parsing" message.
The inability of Saxon within Frame to cope with imported stylesheets and document() XML lookups is a pretty major problem, IMHO.
With Frame 8 (which didn't use Saxon and didn't support result-document) we had to use Structured Frame to save our documents in an intermediate schema and then run several steps external to Frame to sort them out. It looked as though adding Saxon to Frame would allow us to do everything within Frame and greatly simplify our workflow. But now it's starting to look like it's worse, not better.
Copy link to clipboard
Copied
Hi Trevor,
I'll pick this up and see if I can get more assistance from Saxonica. In general Mike Kay has been very helpful when problems have been found. I'll see what I can do. Of course it's not in my power to promise any fixes, but if we do get some improvement it should be possible to include an updated version of Saxon in FrameMaker via a maker.ini change.
I'll get back to you early next week with any progress.
Best regards
Ian
Copy link to clipboard
Copied
An update: this is now with Adobe for response. The error is triggered by a more complicated set of circumstances than was at first apparent.
The document being saved must be being split out into multiple result documents, and at least two of these "sub-documents" must contain cross references to different target documents, and at least one of these target documents must be linked to by more than one "sub-document".
If the document contained these cross-references when it was opened and they have not been changed, save of the document & sub-documents fails with the "parse may not be called while parsing" error. But if the user has added a new cross-reference which meets those criteria, or modifies an existing one, saving the document throws a series of java exceptions and crashes FrameMaker entirely.
I said it was complicated 🙂
cheers
T
Copy link to clipboard
Copied
An update on this: Adobe support provided me with a new saxon9he.jar file and using this one appears to have fixed both issues: the "parse may not be called" error when running a stylesheet that imports/includes other stylesheets, and the crash when saving a document containing multiple external cross references.
I don't know if/when this will be released as part of an official FrameMaker update, but it's good news.
cheers
T