I am in dire need of help. I can post the sample xml files, if necessary … pre-dom4j and post-dom4j respectively. The following is an explanation of the use-case:
I receive an XML via a web service and I am using legacy code (which uses dom4j) to perform some xml transformation. Loading/parsing the original XML into VTD-XML (VTDGen) works fine, no exceptions thrown. However, after loading the xml into dom4j, I noticed some of the element namespace declarations and attributes are re-arranged. Apparently, this re-arrangement causes VTD-XML to throw the following exception:
Exception: Name space qualification Exception: prefixed attribute not qualified
The problem is regarding the attribute (at offset 1827, at the end of the element) in the new XML element: RR_PerformanceSite:FormVersion="1.4"
Any one of the following removes the exception:
- Adding the RR_PerformanceSite xmlns declaration for this element to the root element of the XML doc.
- putting the namespace declaration for 'RR_PerformanceSite' after the 'RR_PerformanceSite:FormVersion' attribute.
- Replacing new element with original element. This SEEMS to lead me to believe that the order of the attributes/ns declarations affects VTD when parsing.
NOTE: I parse the xml doc setting ns aware to 'true' with both xml docs (pre and post-dom4j xml). Also, new VTD objects are created for each xml, pre and post-dom4j, so no cache issues.
I tried to put 'RR_PerformanceSite:FormVersion="1.4"' at the beginning of the element like the original but that does not remove the exception. The offset in the error message is different due to the change of location of the attribute. Does the order of the xmlns declarations affect VTD?
I have looked at the VTDGen source code and cannot figure out why this exception is being thrown. I know where it is thrown but not 'why'.
Why would dom4j parse the new doc and vtd is unable to? Can anyone can shed some light on this?
Thanks for any help you can give!
Here are the xml files:
- good xml … no VTD parsing issues: http://www.blueoctave.com/FTP/VTD_good.xml
- bad xml … VTD has parsing issues: http://www.blueoctave.com/FTP/VTD_bad.xml
This is indeed a bug that has been fixed … check out from cvs the following two files (URL included) FastIntBuffer.java vtd-xml.cvs.sourceforge.net/viewvc/vtd-xml/ximple-dev/com/… FastLongBuffer.java vtd-xml.cvs.sourceforge.net/viewvc/vtd-xml/ximple-dev/com/… Recompile the whole package with the script included in the 2.10 distribution
Thanks to jzhang @ ximpleware for the quick turnaround with the fix!!!
Log in to post a comment.