Re: [xsl] Cannot write more than one result document to the same URI

Subject: Re: [xsl] Cannot write more than one result document to the same URI
From: Dan Vint <dvint@xxxxxxxxx>
Date: Thu, 04 Apr 2013 16:46:31 -0700
I guess what I'm expecting is that the result document is closed once the </xslt:result-document> end tag is found. Instead XSLT seems to keep this memory around that it is there. I'm happy with just over writing the last file created as it is all the same content each time. Yeah maybe inefficient, but I expected it to work. Out of 3000 files I have to process with lots of need for this file splitting I found 2 that complain about writing to the same result document.

With the first posting I wasn't sure where in the processing this was occurring, then I found the files that actually were trying to create the file twice. I still don't understand why this is a problem when the output file should be closed by the time the next write sequence is started.

I was also getting a successful result when I processed what I thought was the problem file as it was difficult to determine in the batch mode as to what file was creating the problem.

..dan


At 02:18 PM 4/4/2013, you wrote:


On 4 Apr 2013, at 21:42, dvint@xxxxxxxxx wrote:

> I understand why this might be an issue to have two different streams
> writing to the same file, but should this always fail just because the
> file is opened twice for write in one stylesheet?

It's not clear what you would like to happen. Do you want to see both outputs appended to the same file? Even though it wouldn't be well-formed XML? Even though the order of the results is unpredictable?

Or would you like one of the outputs to overwrite the other?

In fact, it's not too hard to workaround this problem. Add some kind of random suffix to the URL generated in the result-document href attribute, and write an OutputURIResolver that causes this suffix to be ignored.

Michael Kay
Saxonica

>
> I'm trying to process some DITA content that is using conrefs (think
> xinclude statements). So I have one file that makes 2 references to
> another file to include content from that second file.
>
> We want to change this arrangement such that there is only one includable
> section in a given file. So I'm splitting the second file into 2 new files
> and modifying the references accordingly in the first.
>
> Here is s simplified view of what is going on (for those that know DITA
> please excuse the pseudo code):
>
> Topic file structure:
>
> <concept>
> <h1 conref="file2.xml#sysoutput"></h1>
> <h2 conref=file2.xml#inline"></h2>
> </concept>
>
>
> File2.xml structure:
>
> <concept>
> <h1 id="sysoutput">
> <p>This is the first set of content</p>
> </h1>
> <h2 id="inline">
> <p>this is the second referenced content</p>
> </h2>
> </concept>
>
> Need to change this to be:
>
>
> Topic file structure:
>
> <concept>
> <h1 conref="file2-sysoutput.xml#sysoutput"></h1>
> <h2 conref=file2-inline.xml#inline"></h2>
> </concept>
>
>
> File2-sysoutput.xml structure:
>
> <concept>
> <h1 id="sysoutput">
> <p>This is the first set of content</p>
> </h1>
> </concept>
>
>
> File2-inline.xml structure:
>
> <concept>
> <h2 id="inline">
> <p>this is the second referenced content</p>
> </h2>
> </concept>
>
>
> So my stylesheet is processing the topic file. I have a template that is
> triggered when an @conref attribute is found and it creates the new
> attribute value as well as making the new file.
>
> <xsl:template name="make-conref">
> <xsl:param name="file" as="xs:string"/>
> <xsl:param name="conref-sourcefile" as="xs:string"/>
> <xsl:result-document method="xml" encoding="UTF-8" href="{$file}">
> <concept>
> <xsl:apply-templates select="doc($conref-sourcefile)//*[@id=$target-id]"/>
> </concept>
> </xsl:result-document>
>
> <!-- return the new conref statement to replace the one we found -->
> <xsl:attribute name="conref" select="$newconref"/>
> </xsl:template>
>
> So this template gets the modified filename that uses the id value to make
> it unique, processes the included section and closes the result document
> before continuing to the next content.
>
> I could see this error being raised if one of the conref'd sections
> actually made a circular reference to itself, but I have not been able to
> find this situation.
>
> One other detail is I'm using Kernow to process a directory with the same
> stylesheet. So maybe there is something with the caching going on? I've
> set the multi-threading to use a single thread so there should be no
> collisions there.
>
> Kernow reports that it is net.sf.saxon.trans.XPathException throwing the
> error.
>
> ..dan

--------------------------------------------------------------------------- Danny Vint

Panoramic Photography
http://www.dvint.com

voice: 619-938-3610

Current Thread