Inspiring

Question

Problem with result-document()

Forum|Forum|8 years ago
November 22, 2017
3 replies
1444 views

Some of our XML documents contain "included" subdocuments.

I have a pre-processor stylesheet which replaces every

with

..content from included document..

</included>

Framemaker runs this correctly when loading the outer document and all the subcontent is included. The stylesheet calls

<xsl:apply-templates select="document(@href)/*"/>

to do this and the relative-path-to-doc is evaluated relative to the outer document which was passed to the pre-processor.

The problem I am having is when the full document is saved. There is a complementary post-processor stylesheet which is supposed to identify any

<included href="relative-path-to-doc">...content...</included>,

replace the included element with the include element in the output document, and process all the included content within

<xsl:result-document href="relative-path-to-doc"><xsl:apply-templates ... /></xsl:result-document>

When I run this stylesheet outside of Framemaker it correctly creates the result-document relative to the primary document, regardless of where I call the stylesheet from. Document() and xsl:result-document() are correctly complementary. But within Framemaker it fails with the error

Fatal Error at file C:\Program Files (x86)\Adobe\Adobe FrameMaker 2017\structure\xml\helpcenter\app\post.xsl, line 40, char -1, Message: java.io.FileNotFoundException: Access to the path 'C:\Program Files (x86)\Adobe\Adobe FrameMaker 2017\formats_sub.xml' is denied.

Is this a bug? How could I achieve what I am trying to do here?

Thanks

T

Structured

This topic has been closed for replies.

T

Trevor-NichollsAuthor

Inspiring

Thank you, you've all provided pieces of the puzzle and the problem is solved. It's hard to pick one particular answer as the correct one when you've all contributed, what should I do?!

Ian Proudfoot

Legend

This may be due to security on the folder you are saving to. For the last few versions of Windows, the Program Files folders and sub-folders have been subject to write restrictions. Try to save your files in a different location where saving is unrestricted.

You may need to provide the new path to the xsl stylesheet as a parameter in the XML Application definition in structapps.fm.

I hope this makes the difference.

Ian

R

Russ Ward

Legend

Hi T,

I am not fully able to follow the stylesheet flow, maybe because I've never done anything quite the way that you are. But I thought I might ask a more basic question, which I hope is not insulting. It appears that your stylesheet is attempting to write within the Windows Program Files area, which is typically not writeable by an application. For example, an FM plugin cannot write into the installation area. Could that be the problem? Could you move your structure app files out of Program Files and try it again?

Russ

T

Trevor-NichollsAuthor

Inspiring

The pre and post processing stylesheets are both located within Frame's $STRUCTDIR (in $STRUCTDIR/xml/application/app to be specific). That's where I understood they had to be when I learned Structured Frame with FM7 and FM8. You are correct that the error I am getting is because the post-processor stylesheet is trying to write the output file relative to the location of the stylesheet rather than the location of the file that was being edited. The thing is, that's not how it behaves when I run it external to Framemaker: then it creates the result document relative to the path of the original file.

L

Lynne A. Price

Inspiring

T,

First, a side issue. It is not necessary to put your applications in $STRUCTDIR. You can put them in any directory that is convenient. $STRUCTDIR is simply a convenient location to group files for various applications.

To return to the main point, according to Michael Kay, editor of the XSLT standard, in XSLT 2.0 and XPath 2.0, 4th edition, "The way in which the href attribute is used is deliberately left a little vague..., because the details are likely to be implementation-dependent...ny relative URI used in the href attribute... is interpreted relative to a Base Output URI, which in effect is supplied by the API that invokes the transformation."

Thus, the fact that different processors give different results is not a bug. You can avoid relative URIs by using base-uri() to retrieve the absolute URI to the input document and set href relative to the base URI. The resolve-uri() function might also be helpful.

--Lynne

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded