RE: Error compiling schema

Paul Cooper <[email protected]> Sat, 25 Sep 2010 23:29:50 -0400
Newsgroups gmane.text.xml.xmlbeans.user
Message-ID <C4EA9584673F994A98D793091EAF98DB03192F079A@exchange>
All,

I've successfully rebuilt my library with the 2.4 version of XMLBeans, and have successfully replicated the problem with BigDecimals with that version.

Here is the logging from my server:
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Created new E19010
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1901:2010-08-23 10:15:00.0
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1902:0
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1903:89.392
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1905:1
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1906:1
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1907:4500
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1908:4605
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1909:SC008406
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1910:4625
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1911:-15
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Created new E19010
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1901:2010-08-23 10:16:00.0
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1902:0
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1903:89.51
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1905:1
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1906:1
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1907:4500
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1908:4605
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1909:SC008406
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1910:4625
Sep 25 2010 20:22 | DEBUG  | AbstractXmlBuilder | Added E1911:-15
Sep 25 2010 20:22 | INFO   | XmlPcrBuilder |  >>>>>>>>>>>>>>>>>>>>>>>> FAILED validation:  5329436
Sep 25 2010 20:22 | INFO   | XmlPcrBuilder | Message: W5329436 -- union value '89' does not match any members of 'Procedure in namespace http://www.nemsis.org'
Sep 25 2010 20:22 | INFO   | XmlPcrBuilder |  >>>>>>>>>>>>>>>>>>>>>>>>

And here is the XML output. Clearly there is an issue:
      <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>

Paul

From: Wing Yew Poon [mailto:[email protected]]
Sent: Friday, September 24, 2010 12:45 PM
To: [email protected]
Subject: RE: Error compiling schema

Paul Gillen and Paul Cooper,
if the compilation failure for the EMSDataSet.xsd is the same failure reported in XMLBeans-396 (I don't know what GML is), then please reopen that bug (instead of filing a new bug).
As best as I can see, XMLBeans-396 affects post-2.4.0 XMLBeans (version 2.4.1 is not an actual released version; once 2.4.0 is released, the version number is then changed to 2.4.1 in the src while the next release is in development). From what Paul Gillen reported, the EMSDataSet.xsd compiled successfully using 2.4.0.
For now, Paul Cooper, perhaps you can stick with 2.4.0.
- Wing Yew
________________________________
From: Paul Cooper [mailto:[email protected]]
Sent: Friday, September 24, 2010 12:34 PM
To: [email protected]
Subject: RE: Error compiling schema
Paul,

You have correctly identified my issue. And yes, the schema I'm attempting to compile is the EMSDataSet.xsd from the NEMSIS web site. There is a JIRA bug (XMLBEANS-396) that mentions that the current version of the compiler fails with these errors. Did you modify the source to include the suggested fix? The latest and greatest code DOES have the fix in it, and still generates exactly those errors.

I'm beginning to have a bit more sympathy for the vendors who have to submit XML to us...

Original Paul

From: Gillen, Paul [mailto:[email protected]]
Sent: Friday, September 24, 2010 12:19 PM
To: '[email protected]'
Subject: RE: Error compiling schema

Different Paul here, but this looked interesting.

Presuming from original report this that is EMSDataSet.xsd and related XSDs available from http://www.nemsis.org/softwaredevelopers/downloads/emsDataset.html, and presuming I understand the problem report correctly.

Using downloaded binaries XMLBeans 2.3 and 2.4 compile cleanly.  XMLBeans 2.5 (which despite what is noted below is not listed as the current release on http://xmlbeans.apache.org/sourceAndBinaries/) generates:

C:\development\downloads>C:\development\xmlbeans-2.5.0\bin\scomp xsd\EMSDataSet.xsd -out lib\EMSDataSet.jar
Time to build schema type system: 2.652 seconds
Time to generate code: 21.917 seconds
C:\DOCUME~1\xxxxx\LOCALS~1\Temp\xbean50429.d\src\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:\DOCUME~1\xxxxx\LOCALS~1\Temp\xbean50429.d\src\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:\DOCUME~1\xxxxx\LOCALS~1\Temp\xbean50429.d\src\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:\DOCUME~1\xxxxx\LOCALS~1\Temp\xbean50429.d\src\org\nemsis\impl\E12Impl.java:1225: generatedSetterHelperImpl(org.apache.xmlbeans.XmlObject,javax.xm
l.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
________________________________
From: Wing Yew Poon [mailto:[email protected]]
Sent: Friday, September 24, 2010 3:00 PM
To: [email protected]
Subject: RE: Error compiling schema

The code to set the E19_03 element value is simple:
procInfo.setE1903(proc.getProcedurePerformed().getCode());

Paul,
you might try to print out what you are actually setting E19_03 to (what is the value of proc.getProcedurePerformed().getCode()?).
And how did that code get set in the ProcedurePerformed object?
What I'm getting at is that you should try to trace where your "89" first appeared in your system. Did it come from XMLBeans or did it come from some input to XMLBeans?
- Wing Yew

________________________________
From: Paul Cooper [mailto:[email protected]]
Sent: Friday, September 24, 2010 12:04 AM
To: [email protected]
Subject: RE: Error compiling schema
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:[email protected]]
Sent: Thursday, September 23, 2010 10:26 PM
To: [email protected]
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:[email protected]]
Sent: Thursday, September 23, 2010 7:20 PM
To: [email protected]
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:[email protected]]
Sent: Thursday, September 23, 2010 7:07 PM
To: [email protected]
Subject: RE: Error compiling schema

Paul,
what is this BigDecimal truncation bug that you speak of?
- Wing Yew

________________________________
From: Paul Cooper [mailto:[email protected]]
Sent: Thursday, September 23, 2010 6:59 PM
To: [email protected]
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