Tom,
If the usage pattern is what you are describing, then indeed it seems
that their use of multiple elements with the same QName falls within the
limits of what is allowed in the spec, because two conflicting
definitions are never used in the same document.
In order to handle this with XMLBeans, I would compile SharedTypes.xsd
to a "shared jar", then I would compile each of the top-level Schemas
one at a time, using "shared.jar" and making sure that I use
an .xsdconfig to map each top-level Schema to a different Java package
name to avoid the Java-level conflict you mentioned.
Then, when parsing a file, you have to "know" which of the top-level
Schemas it refers to and use a SchemaTypeLoader with the corresponding
Schema.
It's not as easy as it could be if there were no naming conflicts, but
it should be possible to handle.
Radu
On Fri, 2009-03-27 at 14:44 -0400, Cort, Tom wrote:
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
