Hello,
TIGERS, a standards body that defines data formats for taxes, is defining some
new XML schemas in a way that I don't think is valid according the W3C XML
Schema Recommendations and I'm not sure how to handle it with XML Beans. I've
brought it to their attention several times but they say it isn't an issue.
They are defining multiple global elements within the same namespace, but they
are defining them in different XSD files. Is this valid? Here's a simplified
example of the general design...
* Form123.xsd defines ReturnState root element. Includes SharedTypes.xsd.
Namespace www.example.org
* Form987.xsd defines ReturnState root element. Includes SharedTypes.xsd.
Namespace www.example.org
* ShareTypes.xsd defines a bunch of common types. Namespace www.example.org
In the sample instance documents, Form123.xml has a schemaLocation attribute
pointing to Form123.xsd and Form987.xml has a schemaLocation attribute pointing
to Form987.xsd.
When I run './scomp schemadir' (where schemadir is the directory containing
Form123.xsd, Form987.xsd, and ShareTypes.xsd) I get duplicate global element
name errors. Using the '-allowmdef' option seems to clobber one of the
definitions. I could remove Form987.xsd and compile a JAR for Form123 and
reverse the process to create a JAR for Form987, but I think the first
occurrence of org.example.www.ReturnStateDocument in the classpath would be
used by the JVM thus not actually solving my problem.
Is there a way to specify the Java package name for generated sources so that I
could do something like this...
if (foobar.getSchemaLocation(xml) == FORM_123) {
org.example.www.Form123.ReturnStateDocument form =
org.example.www.Form123.ReturnStateDocument.Factory.parse(xml);
/* more code here */
} else {
org.example.www.Form987.ReturnStateDocument form =
org.example.www.Form987.ReturnStateDocument.Factory.parse(xml);
/* more code here */
}
Thanks in advance for the help!
--
Tom Cort
Systems Developer
Vermont Department of Taxes
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
