Bug #2153
closed
Exception using parse-xml-fragment function with linked tree model
100%
Description
When I executing the XPath expression with s9api:
parse-xml-fragment(\"<alpha>abcd</alpha><beta>abcd</beta>\")
I have obtained the next exception:
Exception in thread "main" java.lang.IllegalStateException: startContent() called more than once
at net.sf.saxon.tree.linked.LinkedTreeBuilder.startContent(LinkedTreeBuilder.java:220)
at net.sf.saxon.event.ProxyReceiver.startContent(ProxyReceiver.java:177)
at net.sf.saxon.event.ProxyReceiver.startContent(ProxyReceiver.java:177)
at net.sf.saxon.event.ReceivingContentHandler.startElement(ReceivingContentHandler.java:351)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:428)
at net.sf.saxon.event.Sender.send(Sender.java:144)
at com.saxonica.functions.xpath3.ParseXmlFragment.evalParseXml(ParseXmlFragment.java:135)
at com.saxonica.functions.xpath3.ParseXmlFragment.evaluateItem(ParseXmlFragment.java:53)
at com.saxonica.functions.xpath3.ParseXmlFragment.evaluateItem(ParseXmlFragment.java:30)
at net.sf.saxon.expr.Expression.iterate(Expression.java:499)
at net.sf.saxon.sxpath.XPathExpression.iterate(XPathExpression.java:163)
at net.sf.saxon.s9api.XPathSelector.iterator(XPathSelector.java:208)
at ro.sync.test.RunXPathWithSaxon.runQueryWithS9API(RunXPathWithSaxon.java:40)
at ro.sync.test.RunXPathWithSaxon.main(RunXPathWithSaxon.java:56)
I have attached a Java file: RunXPathWithSaxon.java that can be used to obtain the reported exception. In my tests I have used the latest Saxon library 9.5.1.7.
Files
Updated by Michael Kay about 10 years ago
- Subject changed from Exception when executing an XPath 3.0 that uses the parse-xml-fragment function to Exception using parse-xml-fragment function with linked tree model
- Category set to XPath conformance
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Priority changed from Low to Normal
The parse-xml-fragment() function fails when used with the LinkedTree model. The error message is
Exception in thread "main" java.lang.IllegalStateException: startContent() called more than once
at net.sf.saxon.tree.linked.LinkedTreeBuilder.startContent(LinkedTreeBuilder.java:220)
What's happening here is that parse-xml-fragment wraps an element .... around the supplied fragment before passing it to the XML parser, and then filters out the startElement0 and endElement() events for this element on their way to the tree builder. There is no attempt to filter out the startContent() event, and where the destination is a LinkedTreeBuilder this causes the indicated exception, because it checks that each startContent() event follows a startElement().
A patch is being raised on the 9.5 and 9.6 branches.
Updated by Radu Pisoi about 10 years ago
I tested the patch committed for this problem in the revision 1023.
Now, when executing the XPath:
fn:parse-xml-fragment("<alpha>abcd</alpha><beta>abcd</beta>")//*
I obtained the expected result, two nodes corresponding to the elements: alpha and beta.
I think that there could be another problem related to the 'document-uri' information attached to the resulted nodes.
If I print in the output the document-URI info, for both nodes I get the URI corresponding to the current working directory.
The same URI is obtained as the result of the function XdmNode.getUnderlyingNode().getSystemID().
I modified the class already attached to print in the output this information:
XPathSelector selector = exec.load();
Iterator<XdmItem> iter = selector.iterator();
if (iter != null) {
for (; iter.hasNext();) {
XdmItem nextItem = iter.next();
System.out.println("------\nNext item: " + nextItem);
if (nextItem instanceof XdmNode) {
XdmNode xdmNode = (XdmNode) nextItem;
NodeInfo node = xdmNode.getUnderlyingNode();
System.out.println("Base URI " + xdmNode.getBaseURI());
System.out.println("Document URI " + xdmNode.getDocumentURI());
System.out.println("Node systemID " + node.getSystemId());
}
}
}
After I run the test, I get the next output:
------
Next item: <alpha>abcd</alpha>
Base URI file:///D:/workspace/TestSaxon/
Document URI file:///D:/workspace/TestSaxon/
Node systemID file:///D:/workspace/TestSaxon/
------
Next item: <beta>abcd</beta>
Base URI file:///D:/workspace/TestSaxon/
Document URI file:///D:/workspace/TestSaxon/
Node systemID file:///D:/workspace/TestSaxon/
Is it correct that the 'document-URI' information to be set for the nodes resulted from evaluation of the parse-document-fragment() function?
Updated by Michael Kay about 10 years ago
Thanks for reporting it. No, I think document-uri() should return empty sequence. It's a bit tricky to always get this right because internally we tend to conflate base URI, system ID, and document URI.
Updated by O'Neil Delpratt about 10 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in version set to 9.5.1.8
bug fix applied to the Saxon 9.5.1.8 maintenance release
Please register to edit this issue
.