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

Re: Cannot write more than one result document to the

Subject: Re: Cannot write more than one result document to the same URI
From: Dan Vint <dvint@xxxxxxxxx>
Date: Thu, 04 Apr 2013 20:22:20 -0700
Re:  Cannot write more than one result document to the
Thanks, I can see that argument. but now you open a can of worms for me. So say your template for b just writes output to the standard result tree (not separate files). Why doesn't the same argument for parallelism apply there?

Probably answering my own question here, I'm guessing the difference is writing to a file more or less serially vs writing to a tree. The processor can write to multiple locations in the tree and keep track of where multiple b outputs should be created, but not as well supported writing to a file from multiple sources (unless your willing to live with jumbled results in the file).

Thanks again.

..dan

At 07:56 PM 4/4/2013, you wrote:
At 2013-04-04 19:37 -0700, Dan Vint wrote:
I can live with the rule, just would like to understand the logic.

Consider the following scenario. An XML document has two elements <b>:


  <a>
    <b id="1">...</b>
    <b id="2">...</b>
  </a>

An XSLT stylesheet uses the built-in template rule for <a> and has a template rule for <b>:

   <xsl:template match="b">
     <xsl:result-document href="output.xml">
       <xsl:copy-of select="."/>
     </xsl:result-document>
   </xsl:template>

If the specification allowed this, then without considering the opportunities of parallelism, one might come to the conclusion that the file "output.xml" would always contain:

<b id="1">...</b><b id="2">...</b>

The problem is that the specification does not require the XSLT processor to complete the processing of the first <b> before starting or even ending the processing of the second <b>. Sure a single-process implementation "X" likely would. But a parallelized (is that a word?) implementation "Y" running on multiple CPUs could very well fully process the second <b> before the first <b> if it chose to do so. Its only obligation is to arrange the resulting tree with the result of processing the first <b> before the result of processing the second <b>. This obligation ensures that the result of processing by "X" is identical to the result of processing by "Y". But there is no obligation on what the processor does to get to that result.

When using <xsl:result-document> the processor is not building the result tree. It is creating a completely separate result. If the instruction required "re-opening" of the file for append, processor "X" likely would produce the expected result, but processor "Y" in the situation above would produce an unexpected result. Two processors would produce two results.

And this is also why one cannot assert that the writing to the file is even finished before the next attempt to write to the file starts. The file handle could very well still be left open by one parallel process when the other is ready to open it for itself. So it can't be used even if the file is opened for write and not for append.

Note that some of my students have come to class thinking that you have to fully complete an <xsl:result-document> before starting another one to another URI, but I tell them that is not the case. You can nest <xsl:result-document> instructions to different URI target locations, and the nested <xsl:result-document> will complete the nested file and resume the "outer" file output when done, without having to close and re-open the outer file. This has been a very handy feature when fragmenting files. And this would be another reason not to allow the same URI to be used.

I know the what now, even though I don't understand why the rule exists ;-)

I hope the explanation above has helped.


. . . . . . . . . Ken

--
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |


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

Panoramic Photography
http://www.dvint.com

voice: 619-938-3610

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.