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]
