If the structure (except for the root element) of instance files of
Form123.xsd and of Form987.xsd are different (which I suspect), then I would
say that, although the schemas are valid, this is VERY BAD practice.
In my opinion, there should be a 1:1 relationship between a standard and a
namespace, i.e. for each different "standard" (or standard version), there
should be a separate namespace.
I have even seen the worst case in HL7-v3-XML where totally different
standards (with different root elements) all belong to the same namespace -
Oh my God ...
J.A.
----- Original Message -----
From: "Radu Preotiuc" <[email protected]>
To: <[email protected]>
Sent: Friday, March 27, 2009 10:56 PM
Subject: Re: Duplicate Global Element Names
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
