I apologize if this is a simple question, but I've stared at XPath
documentation and XJB customization documentation for a couple of hours and
tried a lot of things, but I've run out of ideas.
I'm trying to use JAXB 2.0 to compile some highly interdependent schema files,
all of which are out of my control, and I'm getting name conflicts. So far, my
attempts to resolve the collisions using an external customizations file have
failed. Can someone help?
Here's an excerpt of the offending file:
293 <element name="graphStyle" type="gml:GraphStylePropertyType">
294 <annotation>
295 <documentation/>
296 </annotation>
297 </element>
312 <element name="GraphStyle" type="gml:GraphStyleType" substitutionGroup="gml:_GML">
313 <annotation>
314 <documentation>xxx</documentation>
315 </annotation>
316 </element>
Note that on line 293 there is an element named 'graphStyle' while line 312
has an element named 'GraphStyle', differing only in the capitalization of the
first letter and in type. I get an error message from xjc about two
declarations causing a collision in the ObjectFactory class. The error message
references lines 293 and 312.
I'm assuming that the above is legal, if questionable, schema syntax. But in
any case, since the schema source is out of my control, my only recourse is to
try to fix it with an external customization file. I'm also assuming that the
collision is due to the two nearly-identical names GraphStyle and graphStyle.
I've first tried a customization file like this, attempting to change the
first, lowercase, graphStyle to some other name.
<jxb:bindings schemaLocation="whatever"
node=".//xs:element[@name='graphStyle']">
<jxb:property name="SomeNewName"/>
</jxb:bindings>
This did not help. Then, thinking that maybe XPath wasn't honoring the
capitaliation, I tried further refining the XPath expression to select on the
type attribute too:
<jxb:bindings schemaLocation="whatever"
node=".//xs:element[@name='graphStyle'][@type='gml:GraphStylePropertyType']">
<jxb:property name="SomeNewName"/>
</jxb:bindings>
But I keep getting the same collision errors on lines 293 and 312. What could
be wrong with this approach? Any suggestions?
Thanks,
Johnny S. Tolliver
Oak Ridge National Laboratory
tolliverjs_at_ornl.gov, 865-574-1305