You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xmlbeans.apache.org by David Jencks <da...@yahoo.com> on 2006/07/02 23:35:40 UTC
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: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
RE: Substitution group problems
Posted by Radu Preotiuc-Pietro <ra...@bea.com>.
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:david_jencks@yahoo.com]
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: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
_______________________________________________________________________
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: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org