test:report-value does not write unique URI when result node count > 1000

[GoogleCodeExporter]

Using XSPEC xspec-0.4.0rc1 and SAXON EE 9.3.0.4, I receive the following error:

    Error at xsl:result-document on line 577 of generate-tests-utils.xsl:
    XTDE1490: Cannot write more than one result document to the same URI:
    file:/C:/test/xspec/d56e0.xml
    Transformation failed: Run-time errors were reported

This process fails when trying to write the 2nd file (with the duplicated 
filename) shown below in the sample result xml:

<x:scenario>
    <x:label>Test Label</x:label>
    <x:context> 
        <!--... context xml here ... --> 
    </x:context>
    <x:result href="d56e0.xml"/><!-- result document sucessfully written -->
    <x:test successful="true">
        <x:label>Test Label</x:label>
        <x:result href="d56e0.xml"/><!-- duplicated filename, which fails the process -->
        <!-- any following xml is not actually written... -->
        <x:expect href="d240e.xml"/>
    </x:test>
</x:scenario>

The "test:report-value" template within "generate-tests-utils.xsl" creates a 
result document only if the node count of $value is greater than 1000. Updating 
the template (and related stylesheet templates/call-template) to write a unique 
file should resolve the Saxon error.

Possible resolutions:
(1) Add a new parameter to "test:report-value" template and call-template that 
indicates the xml result context (x:test/x:result)
(2) Change existing 'wrapper-name' param to pass 'x:test/x:result' instead of 
just 'x:result', and remove the parent x:test context when writing the element, 
but use it to help create a unique filename.
(3) Create a 2nd x:result variable that has a new id, which is used when passed 
to test:report-value from the x:text/x:result context.
(4) Remove the logic branch to create a document when the node count is greater 
than 1000; use the standard logic to write within the result xml.
(5) Do not have results over 1000 nodes. ;)

Possible solution (1):
A unique filename can be achieved by adding a parameter that indicates the 
x:scenario/x:test/x:result document is being written instead of the 
x:scenario/x:result document.
(1) Within "generate-xspec-tests.xsl" on line 740 add <with-param 
name="wrapper-context" select="'x:test'"/> to indicate the context of x:result. 
(2) Within "generate-tests-utils.xsl":
    - on line 554 add the <xsl:param name="wrapper-context" select="''"/> (empty default that is not a mandatory param)
    - on line 574 modify the href variable to include the template mode test-result:
      <xsl:variable name="href" as="xs:string" select="concat(generate-id($value[1]), (if ($wrapper-context='x:test') then '_test_result' else ''), '.xml')" />

The XML would then result in a unique filename, e.g.:
<x:scenario>
    <x:label>Test Label</x:label>
    <x:context> 
        .... 
    </x:context>
    <x:result href="d56e0.xml"/>
    <x:test successful="true">
        <x:label>Test Label</x:label>
        <x:result href="d56e0_test_result.xml"/>
        <x:expect href="d240e1.xml"/>
    </x:test>
</x:scenario>

Assumptions:
- This is a recommendation that resolves my issue. I assume there are other 
ways, and I have not looked into whether or not the process could be improved 
otherwise.
- I have not tested using other Saxon versions. It is possible older versions 
of Saxon allow writing multiple documents to the same URI.

Thanks!

Original issue reported on code.google.com by [email protected] on 17 Aug 2012 at 7:01

[GoogleCodeExporter]

This error also occurs with Saxon 9.4.

As a quick fix, I amended your approach no. 5) by changing the threshold from 
1000 to 1000000 :) 

Original comment by [email protected] on 21 Feb 2013 at 4:51

[GoogleCodeExporter]

> As a quick fix, I amended your approach no. 5) by changing
> the threshold from 1000 to 1000000 :)

Haha! I did the same exact thing before finding this issue. Would be nice to 
get this resolved for testing large result sets as a whole.

Original comment by [email protected] on 13 Sep 2013 at 3:10

[GoogleCodeExporter]

Apparently I like over-engineered solutions. :) I figured if it was intended to 
write a file, it should. Good to hear the quick fix works.

Original comment by [email protected] on 13 Sep 2013 at 3:25