Forums » Help »
XTDE1490 Error with 8.8
Added by Anonymous almost 18 years ago
Legacy ID: #3934843
Legacy Poster: jfenlason (jfenlason)
I'm trying to upgrade from 8.7.3 to 8.8 and I'm getting the error below. It worked
fine in 8.7.3 and is failing when the only thing that changed is the updated Saxon. I
haven't been able to find much on the XTDE1490 error. Any suggestions or tips would be
greatly appreciated. Thanks in advance. , Josh. Warning: at xsl:stylesheet on line 13 of
file:///D:/viewstore/jdf_X10View/Windchill/codebase/wt/epm/test/ixb/swizzleUfid.xsl:
Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor Error at xsl:value-of on line
20 of
file:///D:/viewstore/jdf_X10View/Windchill/codebase/wt/epm/test/ixb/swizzleUfid.xsl:
Failed! XTDE1490: Cannot write an implicit result document if an explicit result
document has been written to the same URI:
file:/D:/viewstore/jdf_X10View/Windchill/temp/epmTest/ixb/jdfTAG-EPMSepFamilyTable-19.xml
wt.util.WTException Nested exception is: ; SystemID:
file:///D:/viewstore/jdf_X10View/Windchill/codebase/wt/epm/test/ixb/swizzleUfid.xsl;
Line#: 20; Column#: -1 net.sf.saxon.trans.DynamicError: Cannot write an implicit result
document if an explicit result document has been written to the same URI:
file:/D:/viewstore/jdf_X10View/Windchill/temp/epmTest/ixb/jdfTAG-EPMSepFamilyTable-19.xml
at net.sf.saxon.Controller.checkImplicitResultTree(Controller.java:484) at
net.sf.saxon.event.ImplicitResultChecker.firstContent(ImplicitResultChecker.java:57) at
net.sf.saxon.event.ImplicitResultChecker.startElement(ImplicitResultChecker.java:30) at
net.sf.saxon.event.NamespaceReducer.startElement(NamespaceReducer.java:54) at
net.sf.saxon.event.ComplexContentOutputter.startContent(ComplexContentOutputter.java:481)
at
net.sf.saxon.event.ComplexContentOutputter.characters(ComplexContentOutputter.java:136)
at net.sf.saxon.instruct.ValueOf.processLeavingTail(ValueOf.java:200) at
net.sf.saxon.instruct.Block.processLeavingTail(Block.java:353) at
net.sf.saxon.instruct.Instruction.process(Instruction.java:91) at
net.sf.saxon.instruct.ElementCreator.processLeavingTail(ElementCreator.java:250) at
net.sf.saxon.instruct.Copy.processLeavingTail(Copy.java:152) at
net.sf.saxon.instruct.Template.applyLeavingTail(Template.java:99) at
net.sf.saxon.instruct.ApplyTemplates.applyTemplates(ApplyTemplates.java:319) at
net.sf.saxon.instruct.ApplyTemplates.defaultAction(ApplyTemplates.java:351) at
net.sf.saxon.instruct.ApplyTemplates.applyTemplates(ApplyTemplates.java:312) at
net.sf.saxon.Controller.transformDocument(Controller.java:1602) at
net.sf.saxon.Controller.transform(Controller.java:1426) at
wt.epm.test.ixb.IxHelper.transformIxbDocuments(IxHelper.java:468) at
wt.epm.test.ixb.IxHelper.swizzleUfidAndDoImport(IxHelper.java:286) at
wt.epm.test.ixb.IxHelper.swizzleUfidAndDoImport(IxHelper.java:263) at
wt.epm.test.ixb.IxTest001.test(IxTest001.java:226) at
wt.epm.test.EPMTestBase.test(EPMTestBase.java:161) at
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
java.lang.reflect.Method.invoke(Method.java:585) at
junit.framework.TestCase.runTest(TestCase.java:164) at
junit.framework.TestCase.runBare(TestCase.java:130) at
junit.framework.TestResult$1.protect(TestResult.java:110) at
junit.framework.TestResult.runProtected(TestResult.java:128) at
junit.framework.TestResult.run(TestResult.java:113) at
junit.framework.TestCase.run(TestCase.java:120) at
junit.framework.TestSuite.runTest(TestSuite.java:228) at
junit.framework.TestSuite.run(TestSuite.java:223) at
junit.framework.TestSuite.runTest(TestSuite.java:228) at
junit.framework.TestSuite.run(TestSuite.java:223) at
junit.textui.TestRunner.doRun(TestRunner.java:115) at
junit.textui.TestRunner.start(TestRunner.java:179) at
junit.textui.TestRunner.main(TestRunner.java:137)
Please register to reply
Legacy ID: #3935061
Legacy Poster: Michael Kay (mhkay)
This change was made in Saxon to fix a non-conformance with the spec. From the
information you've supplied, the error might mean exactly what it says, i.e. that you've
written a document using xsl:result-document and you're now trying to read the same
document using the document() function (which isn't allowed because it makes your
results dependent on order of execution). Another possible cause of the error is this
bug:
https://sourceforge.net/tracker/index.php?func=detail&aid=1552815&group_id=29872&atid=397617
Without actually seeing what your stylesheet is doing, I can't be more specific.
Legacy ID: #3935066
Legacy Poster: Michael Kay (mhkay)
Sorry, misread the error. It's getting late... This one is closely related, but
slightly different. The "implicit" result document is the one written
without any call to xsl:result-document, and it's URI is what you specify in the -o
option on the command line. An "explicit" result document is one
written using xsl:result-document. Previous Saxon releases allowed you to write more
than one document to the same URI (the second would overwrite the first). Saxon 8.8
catches this error, as required by the spec.
Legacy ID: #3937797
Legacy Poster: jfenlason (jfenlason)
Thanks for the response Michael. I think I'm getting a little closer to narrowing
down the problem. When I use the same net.sf.saxon.Controller to transform multiple xml
documents, I see the error reported earlier. If I call Controller.reset() prior to the
next transform() call, it seems to work fine. Would this be a bug in our code? Or in
Saxon? Does reset() cause the xsl to be reread? Thanks. , Josh.
Legacy ID: #3937817
Legacy Poster: Michael Kay (mhkay)
reset() according to the JAXP API is supposed to reset the Transformer to its
initial state, but I've always worked on the assumption that someone calling reset() and
reusing the same Transformer, rather than simply creating a new Transformer, is hoping
to gain some efficiencies by reusing resources. So in particular, reset() doesn't clear
the source document pool. This means that if your second transform calls doc() using a
URI that was already used in the first transformation, you get the same document; it
also means that you aren't allowed to write to a URI in the second transformation if you
read from it in the first, I think. Messy. If I were you I would avoid these problems by
not reusing the Transformer/Controller; instead if you need documents to be kept in
memory between transformations, control it yourself at the application level.
Please register to reply
.