[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: loop timing and result-document flush

Subject: Re: loop timing and result-document flush
From: Abel Braaksma <abel.online@xxxxxxxxx>
Date: Wed, 02 May 2007 16:39:55 +0200
Re:  loop timing and result-document flush
Hi Duane,

see my comments below...



Duane Gran wrote:
XSL experts,

I have an XSL which loops over a set of elements in search of links and creates a result document for the link. In some cases there is more than one link to the same anticipated document, so I use the doc-available() to test first for its existence before creating the file.

which is good.


This is intended to avoid a DynamicError related to writing more than one result document to the same URI.

which is bad, you won't be able to: regardless your structure, or the use of the doc-available() function, having an instruction xsl:result-document that writes more than once to the same target is illegal and raises an (I believe recoverable) error.



<snip />


BUILD FAILED
/Users/dgran/dev/rose/build.xml:395: The following error occurred while executing this line:
/Users/dgran/dev/rose/build.xml:77: net.sf.saxon.trans.DynamicError: Cannot write more than one result document to the same URI: file:/Users/dgran/dev/rose/build/zoom/1-1861.wrenn.320-321.img.html

Indeed.



In the first case, the file (1-1861.wrenn.320-321.img.html) is correctly created because it doesn't exist yet. In the second case the doc-available() method should return true

sorry, no: it will always return false() during one run, and writing twice to the same target will always return and error, though as a result of optimization, the second may not always occur.


This is because in XSLT you can't predict, in any way, the order of execution. Hence, it is impossible to say "first" case and "second" case (well, you can say it, but the processor may or may not run in that order).

and skip the result-document command, but it fails to work. My hypothesis is that the result-document() method isn't finished flushing before the call to doc-available() is made.

No, doc-available() always returns the same result, and regardless of its result, xsl:result-document may not write more than once to the same URI.



Assuming my guess is correct, is there a way in XSL to assure that the document is finished writing before continuing to the next iteration in the loop?

No, this is imperative thinking. Try to think declarative ;)
It is impossible to control flushing, because it is impossible to predict the execution order.


Maybe there is another way of skinning this cat.

Yes, see below.



I welcome suggestions. I'm using Saxon 8-7-3j. Below is a simplified version of my stylesheet:

Please update, you use a version that was written based on an earlier draft of the standard. Version 8.9 is now current.



<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
<xsl:template match="/">
<xsl:for-each select="ram|//repro|//page|//figure">

why use for-each? Consider xsl:apply-templates.


<xsl:variable name="zoomhtml">
<xsl:text>build/zoom/</xsl:text>
<xsl:value-of select="@image"/>
<xsl:text>.img.html</xsl:text>
</xsl:variable>
<xsl:message>
test for doc <xsl:value-of select="$zoomhtml"/> available: <xsl:value-of select="doc-available($zoomhtml)"/>

Remember, since the order of the execution is undetermined, so is the order of the output of the xsl:message instruction.


      </xsl:message>
      <xsl:choose>
        <xsl:when test="doc-available($zoomhtml)"/>

You really don't need this... (see below)


<snip />


Here's a solution that I normally use. Take all URIs that you want to write to, pack them in a sequence and deduplicate them (use the function distinct-values or similar) and go from there (if possible) or, if you can't, you can use a micro-pipeline. I.e., the first transforms and changes the input and adds _1, _2 etc to the names, to ensure uniqueness, the second is the transformation where you create the actual result document.

Both approaches will work always. The first dismisses writing documents to URIs that are duplicates, but uses the original URI, the second always writes something, but changes the target URI a bit, which may or may not be convenient. Whichever you choose is up to your requirements.

HTH,

Cheers,
-- Abel Braaksma

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.