On Jun 18, 2006, at 1:55 PM, Gianny Damour wrote:
Hi,
Is there a way to do this substitution of JACC implementation by
providing a substitutionGroup attribute to the security element?
<giant snip>
I think this is the best solution, although there are some problems.
It appears that substitution groups may not really be intended to
provide runtime-extensible element support, at least xmlbeans doesn't
work that way. I think I have a solution.
Xmlbeans' ideas about substitution groups are that it only recognizes
the substitutions that are in the set of schemas compiled at the same
time as the element being substituted for. Later schemas compile
just fine but the list of substitute qnames is hardcoded in the
generated code for the substitutable element and also in the binary
xsb encoding of the schema. It might be possible to add more qnames
into the object model the xsb is deserialized into, but I don't see
a reasonable way to modify the hardcoded list in the generated code.
What I've come up with that appears to work is:
- use substitution groups in the schemas. This makes it plausible to
see what is intended, unlike with the use of any.
- track substitution group elements ourselves, so we can dynamically
change recognized substitution groups as builders are added. I'm
less sure about tracking removing builders. In this case the
elements wouldn't get deployed but we wouldn't get an error.
- modify our response to validation failures to ignore those caused
by unrecognized substitution group elements
- use the XmlObject.selectChildren(QNameSet) method to get the
substitution group elements based on our tracking of the QNames in
the substitution group.
I hope to iron out the remaining wrinkles shortly and submit an
updated patch for review.
thanks
david jencks
