Wing Yew, Thanks for the response. I have no idea what version of XMLBeans we *were* using....I downloaded it and built our schema jar in March of 2006. We did not find this error until we started attempting to export data earlier this year. And yes, the version I'm using now is built from the latest code checked out from the repository.
Here's the section of the schema in question: -<http://www.nemsis.org/media/XSD/E19_InterventionProcedure.xsd> < <xs:element name="E19_03" type="Procedure"> -<http://www.nemsis.org/media/XSD/E19_InterventionProcedure.xsd> < <xs:annotation> < <xs:documentation>The procedure performed on the patient</xs:documentation> </xs:annotation> </xs:element> Here's the definition of the "Procedure" type: <xs:simpleType name="Procedure"> <xs:annotation> <xs:documentation>The procedure performed on the patient</xs:documentation> </xs:annotation> <xs:union memberTypes="ProcedureCPTCode NullValues" /> </xs:simpleType> And here's the definition of the "ProcedureCPTCode" referenced above (this is a subset, it's a long list; these are EMS procedure codes): <xs:simpleType name="ProcedureCPTCode"> <xs:restriction base="xs:decimal"> <xs:enumeration value="89.391"> <xs:annotation> <xs:documentation>Capnography (CO2 Measurement)</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="89.392"> <xs:annotation> <xs:documentation>Pulse Oximetry</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="89.510"> <xs:annotation> <xs:documentation>Cardiac Monitor</xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> The code to set the E19_03 element value is simple: procInfo.setE1903(proc.getProcedurePerformed().getCode()); And the method getCode() is defined: private BigDecimal myCode; public void setCode(BigDecimal code) { myCode = code; } public BigDecimal getCode() { return myCode; } You are correct about the bug we are seeing: we are setting the value to 89.51 but the XML output is 89. The XML in my last email was copied directly from the XMLBeans output file. And yes, now that I look at it, 89.51 will not equal 89.510, but that's a problem for another day. I just found the email my co-worker sent just before he left, and it turns out he was referencing the same bug I referenced below, so there is a high probability that he had no idea what he was talking about. Nonetheless, we are clearly having a problem... Paul From: Wing Yew Poon [mailto:wing.yew.p...@oracle.com] Sent: Thursday, September 23, 2010 10:26 PM To: user@xmlbeans.apache.org Subject: RE: Error compiling schema Paul, you'll have to explain a bit more what the bug is. Can you excerpt the part of your schema that defines the type of the E19_03 element? Also, how is the value of the element set? Is the bug that you're setting E19_03 to 89.51 but when the XMLObject marshalled, you get 89 in E19_03? What version of XMLBeans are you using? Am I correct in my understanding that you were using 2.5 and seeing a bug consistently, and then you switched to using XMLBeans built from the latest in the svn trunk and now see the bug intermittently? There haven't been that many code checkins since 2.5 was released. How did your co-worker know that the bug was "fixed in the source but NOT fixed in version 2.5" (meaning fixed after 2.5?)? - Wing Yew ________________________________ From: Paul Cooper [mailto:pcoo...@emspic.org] Sent: Thursday, September 23, 2010 7:20 PM To: user@xmlbeans.apache.org Subject: RE: Error compiling schema Wow, I was hoping someone on the list would instantly know what I was talking about. :) We are building an XML file from Oracle data. Periodically we get the following error when validating the XML: W5329436 -- union value '89' does not match any members of 'Procedure in namespace http://www.nemsis.org' Here is the section of the XML that is in question: <E19> <E19_01_0> <E19_01>2010-08-23T17:15:00.000Z</E19_01> <E19_02>0</E19_02> <E19_03>89.392</E19_03> <E19_05>1</E19_05> <E19_06>1</E19_06> <E19_07>4500</E19_07> <E19_08>4605</E19_08> <E19_09>SC008406</E19_09> <E19_10>4625</E19_10> <E19_11>-15</E19_11> </E19_01_0> <E19_01_0> <E19_01>2010-08-23T17:16:00.000Z</E19_01> <E19_02>0</E19_02> <E19_03>89</E19_03> <E19_05>1</E19_05> <E19_06>1</E19_06> <E19_07>4500</E19_07> <E19_08>4605</E19_08> <E19_09>SC008406</E19_09> <E19_10>4625</E19_10> <E19_11>-15</E19_11> </E19_01_0> </E19> As you see above, there are two E19_01_0 sections, one has a E19_03 value of 89.392, and the other has the value of 89. Unfortunately, the second value SHOULD be 89.51. My cow-orker (who has since left the company) indicated that this was a known problem with the version of XMLBeans we were using, and had been fixed in the source but NOT fixed in version 2.5....we'd have to download the source and build it ourselves. Prior to building and deploying the most recent source, we were having this truncation problem on every one of these records. Now, we get it randomly. Thanks for the quick response! Paul From: Wing Yew Poon [mailto:wing.yew.p...@oracle.com] Sent: Thursday, September 23, 2010 7:07 PM To: user@xmlbeans.apache.org Subject: RE: Error compiling schema Paul, what is this BigDecimal truncation bug that you speak of? - Wing Yew ________________________________ From: Paul Cooper [mailto:pcoo...@emspic.org] Sent: Thursday, September 23, 2010 6:59 PM To: user@xmlbeans.apache.org Subject: Error compiling schema Greetings, list. Longtime user of older versions of XMLBeans, and now am trying to work around BigDecimal truncations when generating XML from data. I have downloaded the source from svn, compiled it, and am attempting to build my schema library. My compilation fails with the following errors: C:\Dev\Projects\PreMIS_MultiState2\devlib\test>scomp -src genXmlBeansSrc -out EMSDataSetXMLBeans.jar NEMSIS\EMSDataSet.xsd Time to build schema type system: 2.124 seconds Time to generate code: 4.917 seconds C:\Dev\Projects\PreMIS_MultiState2\devlib\test\genXmlBeansSrc\org\nemsis\impl\E08Impl.java:147: generatedSetterHelperImpl(org.apache.xmlbeans.XmlObject,javax.xml.namespace.QName,int,short) in org.apache.xmlbeans.impl.values.XmlObjectBase cannot be applied to (java.lang.Object,javax.xml.namespace.QName,int,short) generatedSetterHelperImpl(e0801, E0801$0, i, org.apache.xmlbeans.impl.values.XmlObjectBase.KIND_SETTERHELPER_ARRAYITEM); ^ C:\Dev\Projects\PreMIS_MultiState2\devlib\test\genXmlBeansSrc\org\nemsis\impl\E09Impl.java:151: generatedSetterHelperImpl(org.apache.xmlbeans.XmlObject,javax.xml.namespace.QName,int,short) in org.apache.xmlbeans.impl.values.XmlObjectBase cannot be applied to (java.lang.Object,javax.xml.namespace.QName,int,short) generatedSetterHelperImpl(e0901, E0901$0, i, org.apache.xmlbeans.impl.values.XmlObjectBase.KIND_SETTERHELPER_ARRAYITEM); ^ C:\Dev\Projects\PreMIS_MultiState2\devlib\test\genXmlBeansSrc\org\nemsis\impl\E12Impl.java:817: generatedSetterHelperImpl(org.apache.xmlbeans.XmlObject,javax.xml.namespace.QName,int,short) in org.apache.xmlbeans.impl.values.XmlObjectBase cannot be applied to (java.lang.Object,javax.xml.namespace.QName,int,short) generatedSetterHelperImpl(e1208, E1208$10, i, org.apache.xmlbeans.impl.values.XmlObjectBase.KIND_SETTERHELPER_ARRAYITEM); ^ C:\Dev\Projects\PreMIS_MultiState2\devlib\test\genXmlBeansSrc\org\nemsis\impl\E12Impl.java:1225: generatedSetterHelperImpl(org.apache.xmlbeans.XmlObject,javax.xml.namespace.QName,int,short) in org.apache.xmlbeans.impl.values.XmlObjectBase cannot be applied to (java.lang.Object,javax.xml.namespace.QName,int,short) generatedSetterHelperImpl(e1210, E1210$14, i, org.apache.xmlbeans.impl.values.XmlObjectBase.KIND_SETTERHELPER_ARRAYITEM); ^ 4 errors BUILD FAILED A web search reveals a JIRA bug (XMLBEANS-396) logged on this very problem. I have investigated the referenced XMLBeans source to apply the suggested fix, and I find that both instances of the fix have already been applied in SchemaTypeCodePrinter.java. All of this is to work around the BigDecimal truncation bug, which I can seem to find no reference to on the web...a cow-orker who was originally assigned this issue indicated that there was a fix for this bug that had been checked in but was not included in the latest build. We have checked out the source from SVN, built the three required jar files, but we are still randomly having the issue with BigDecimal values being truncated. Any help would be HUGELY appreciated. Paul Cooper Project Manager EMS Performance Improvement Center 100 Market Street Chapel Hill, NC 27516 (919) 843-0201
