On 04.04.2013, at 23:18, Michael Kay <mike(_at_)saxonica(_dot_)com> 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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--