Please report Saxon-specific problems to the saxon-help list (or forum)
available via the saxon project at sourceforge.net.
Writing a document using xsl:result-document and reading the same document
using document() or doc() is not allowed by the XSLT 2.0 specification. Note
that there is no such thing as an "earlier step in the same XSL" - the order
in which instructions are evaluated is not defined, so there is no way of
knowing whether the read comes before the write, or after it: this is the
reason for this rule. It's possible that Saxon 9.2 is enforcing the rule
more rigorously than Saxon 9.1 did, for example it may be better at
recognizing the equivalence of similar URIs.
(However, if you try hard enough you can always find URIs for reading and
writing that are sufficiently different that Saxon won't recognize that they
actually refer to the same resource, and you can thereby circumvent the
rule. You just have to take the consequence that you can't be 100% sure
whether you are reading the document before or after writing it.)
It's also possible that the error is spurious: there's a recent bug with
these symptoms, see
https://sourceforge.net/tracker/?func=detail&aid=2986119&group_id=29872&atid
=397617. But from your description, it looks as if the stylesheet is doing
what the spec doesn't allow.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
-----Original Message-----
From: Stephen Arbour [mailto:sarbour(_at_)maned(_dot_)com]
Sent: 14 April 2010 18:29
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: [xsl] Strange Saxon error
Hi all,
We have a customer that was using Saxon 9.1.0.7j using an
XSLT transform that was created by a third party. When they
upgraded to a version that uses Saxon 9.2.0.2, they started
receiving this error:
net.sf.saxon.trans.XPathException: Cannot read a document
that was written during the same transformation:
file:/C:/Program%20Files/K4%20XML%20Exporter/data/xsl/temp/21m
issouri4.xml
However, using the same XSLT in Oxygen 11 using 9.2.0.6 (HE,
PE), I can't recreate the error. It only appears when Saxon
is called by the application we support.
The XSL itself does indeed perform operations on files
created by earlier steps in the same XSL. Is this no longer a
supported workflow, but somehow Oxygen is intervening where
the standalone Saxon jars do not?
Thanks in advance for your help!
Stephen Arbour, MBA/TM
Senior Director of Product Management
MEI
610 Old York Road, Suite 250, Jenkintown, PA 19046
Phone: 215-886-5662 x291
Fax: 215-886-5681
Email: sarbour(_at_)maned(_dot_)com<mailto:sarbour(_at_)maned(_dot_)com>
<mailto:LBruce(_at_)maned(_dot_)com>AIM: sarbourmei
http://www.maned.com<http://www.maned.com/>
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--