Sorry for taking this long to answer... You are right, it's currently a limitation of XMLBeans that we do not support substitution groups "across jars" i.e. when one of the members of a substitution group is compiled at a different (later) time than the head of the substitution group.
Please note however that no binding tool that I know of supports what you are describing (or for that matter has support for substitution groups even to the level that XMLBeans does), so this never felt like a big limitation to me. The problem with trying to support it is that it implies that everytime a new element is encountered (during either validation or unmarshalling), it must be first looked up in the typesystem so that potential substitution group membership is ascertained. You can never be sure that it is not this element that will trigger loading of a new typesystem. Then, probably all elements seen will have to be cached etc. So all this tends to be extremely expensive, especially since during XmlBeans unmarshalling the same element will be "visited" multiple times in some cases! Ant that's _even if_ one doesn't ever use substitution groups in the way you are trying to use them, which I think is the 99% scenario (more like 99.9% really). Of course, the NPE in the Validator is an issue, the code is basically expecting that once the state.visit() call in line 297 succedeed there is no reason that the _globalTypes.findElement( name ) will return null, but if you have a repro, I'll take a look and see why this happens. But in order to have it work smoothly then you either have to re-compile the "head" element when substitutions for it are added so they can be taken into account, or we would need to add a special option to XmlBeans to handle this case, and figure out how to do it efficiently. Radu -----Original Message----- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Sunday, July 02, 2006 2:36 PM To: dev@xmlbeans.apache.org Subject: Substitution group problems I'm having some problems using xmlbeans with substitution groups the way I want. I think the problems are caused by a difference in point of view: it appears that xmlbeans thinks all the substitution group members and their schemas are known at the time the base element schema is compiled, whereas I want to use substitution groups to dynamically extend schemas with schemas that are not known at the time the base element schema is compiled. I've run into one big problem that I might be able to work around by constructing my own type loader: This code from Validator gives an assertion error or NPE if the type loader in use doesn't happen to know about a particular substitution group element: assert currentParticle.getParticleType() == SchemaParticle.ELEMENT; //line 359 // If the current element particle name does not match the name // of the event, then the current element is a substitute for // the current particle. Replace the field with the global // element for the replacement if (! currentParticle.getName().equals(name)) { if (((SchemaLocalElement) currentParticle).blockSubstitution()) { emitFieldError( event, XmlErrorCodes.PARTICLE_VALID$BLOCK_SUBSTITUTION, new Object[] { QNameHelper.pretty(name) }, name, state._type, null, XmlValidationError.ELEMENT_NOT_ALLOWED, state._type); _eatContent = 1; return; } SchemaGlobalElement newField = _globalTypes.findElement(name); assert newField != null; <<<<<<<<<newField will be null if type loader is unaware of substituted element if (newField != null) { elementField = newField; _localElement = newField; } I think it would be plausible to emit a typed error in case an unknown element is found in these circumstances, rather than producing an NPE. If this were done I could check for these errors and ignore them. In addition, while I haven't investigated everything about how substitution groups are dealt with, it looks like a lot of the code could be modified so loading type systems "later" could modify the tracking of substitution group allowed elements. However some of this knowledge is currently hardcoded in generated code. Before I spend a lot more time looking at this I wonder if others have already considered this situation and have opinions about whether pursuing it is a good idea, directions to look in, or other advice. thanks david jencks --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
