I think this all ties in to how we construct the dynamic deployment module for a module we are trying to deploy.
There's certainly no need for the namespace to be included in the gbean name of the builder. Builders are going to have to register with a framework somehow: currently they either register with Deployer if they are ConfigBuilders or have references from the EarBuilder or a ModuleBuilder. A builder gbean can certainly have a read-only namespace attribute, or call a registration method with the namespace as a parameter.
The "type" and "namespace" keys provide a unique locator for a service by defining what it is (a builder that handles XML instances) and how things of that type can be differentiated (by the namespace it handles). That is sufficient to allow this service to located by anything that wants an XML document handled.
This seems simpler than inventing a proprietary registration mechanism. We already have a GBean registry, lets use it.
I'm not yet convinced that the tradeoff of eliminating complete validation of a plan is worth the flexibility of an any element with dynamic extension registration.
I have reservations as well, primarily that the user will need to deal with an ever increasing number of fairly small XML namespaces and the maintenance problems that they will incur with upgrades.
I would prefer to see fewer, larger namespaces that incorporate common elements by inclusion with schema override. This also will have advantages for validation. Yes it means more work for us in producing and maintaining the schema definitions, but we do that once rather than forcing users to deal with it in every plan instance.
However, this does seem to be better than the original mechanism of placing CDATA inside attribute values.
-- Jeremy
