Tim, Thanks for the reply. This schema is a national standard for the submission of Emergency Medical Services incident data, and has been in the public for 5 years. I can't change the schema. The database column SHOULD have been a string, and since it isn't, is going to cause some major issues (the 89.510 is being truncated to 89.51 by the database). I suspect I will HAVE to change it.
And the form would be a combobox of values, so validation isn't really an issue. The XML is being generated from a web application, a standard servlet-based app (using a proprietary framework, the bane of my existence)...and the provided XML snippet is generated in a loop....the first time through the loop the 89.51 gets truncated, the second time the 89.392 is generated. It's very odd.... But thanks for the ideas! Paul -----Original Message----- From: Tim Watts [mailto:t...@cliftonfarm.org] Sent: Friday, September 24, 2010 6:20 AM To: user@xmlbeans.apache.org Subject: RE: Error compiling schema Intermittent errors usually lead me to suspect a threading issue -- either in your code or XmlBeans. Is the marshaling in your code being handled in another thread? Or perhaps there are multiple threads doing the export work from the database? Can anyone on the list assert how thread-safe the XmlBeans marshaling is? Are there circumstances in which the marshaling would NOT be thread-safe? As a workaround, would it be possible to convert CPTCode to a string and see if the problem persists? (Side issue: Unless you're doing actual math with the value, it seems like string would be a better base since it's an enum. And you could validate the form with a reg-ex.) On Fri, 2010-09-24 at 03:03 -0400, Paul Cooper wrote: > 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: > > - < <xs:element name="E19_03" type="Procedure"> > > - < <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. J > > > > 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.name > space.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_ARRAYI > TEM); > > ^ > > C:\Dev\Projects\PreMIS_MultiState2\devlib\test\genXmlBeansSrc\org > \nemsis\impl\E09Impl.java:151: > generatedSetterHelperImpl(org.apache.xmlbeans.XmlObject,javax.xml.name > space.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_ARRAYI > TEM); > > ^ > > C:\Dev\Projects\PreMIS_MultiState2\devlib\test\genXmlBeansSrc\org > \nemsis\impl\E12Impl.java:817: > generatedSetterHelperImpl(org.apache.xmlbeans.XmlObject,javax.xml.name > space.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_ARRAYI > TEM); > > ^ > > C:\Dev\Projects\PreMIS_MultiState2\devlib\test\genXmlBeansSrc\org > \nemsis\impl\E12Impl.java:1225: > generatedSetterHelperImpl(org.apache.xmlbeans.XmlObject,javax.xml.name > space.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_ARRAYI > TEM); > > ^ > > 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 > > ________ It has been my experience that folks who have no vices have very few virtues. -- Abraham Lincoln --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org For additional commands, e-mail: user-h...@xmlbeans.apache.org
