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: Christian Roth <roth@xxxxxxxxxxxxxx>
Date: Mon, 10 Jun 2013 15:51:31 +0200
On 04.04.2013, at 23:18, Michael Kay <mike@xxxxxxxxxxxx> 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?
>
> [...]
> 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.

I am in the same situation as the OP, i.e. I need to separate out a certain
element of the input XML into its own file. Processing requirements lead to
the situation that this element can occur multiple times in the output (in
some sort of a recursive manner), so that figuring out an XPath that is only
true for exactly one single such occurrence of that element during processing
would be a nightmare.

Therefore I am now considering your suggestion, Mike, as above to make
result-document's @href URLs unique by appending a random number, then strip
it again in a custom OutputURIResolver. However, I think additional care has
to be taken here, because as you say later in this thread, the processing of
multiple xsl:result-document instructions could be parallel. Wouldn't that
mean that these (c/w)ould write to that resolved, actual output URL
simultaneously and therefore  in an interleaved manner, completely corrupting
the contents of the resulting file?

As I understand it at this time, the algorithm needs to be (in order of
execution):

OutputURIREsolver
SEQ  IN                                   OUT
1    file:/externalized.xml-RNDzuwjkt     file:/externalized.xml
2    file:/externalized.xml-RNDuchajs     /dev/null
...
n    file:/externalized.xml-RNDqcnmgd     /dev/null

i.e. only the first call returns the desired URL, all subsequent ones that
would result in an already mapped URL point to the trash (or a unique file in
/tmp/ to be cleaned up automatically).

Am I understanding this correctly?

Regards
Christian

Current Thread