In fact, I do agree with you that it is very bad practice and the people designing the Schemas that you are using should listen, because their goal after all is to design Schemas that are easy to use and encourage adoption. (Then again, you mentioned something about taxes, so in that case probably the goal is to make it difficult :-p)
I was just saying that the XMLSchema specification talks very little about how Schema documents are put together to form a "Schema", so while it clearly says that within the same "Schema", all the elements must have different QNames, it does leave the door open as to how a "Schema" is composed (from Xsd documents). Radu On Fri, 2009-03-27 at 23:09 +0100, Jozef Aerts - XML4Pharma wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
