OK, well, I hadn't considered the idea of preserving Aegis as an XML-bean-like item outside of CXF. Last night's work will have to be somewhat rewound in that case.
My revised approach would be to stop having the data binding and the context communicate through properties of the service. The relationship between a databinding and a context would be parallel to that in JAXB. As with JAXB, my revised vision would be that a CXF user could do what they needed to do using the AegisDatabinding object in just about all cases. On the type mapping front, let me try to state all my confusion in one place. I don't think that eliminating delegation is a good idea. Let's center the discussion on a Context (which I'd propose, in passing, to rename to AegisContext). So, I create a context. It makes a type mapping registry. Unless told otherwise, it makes a default mapping object for the default type mappings. Now, how many other mappings should it have, and for what reasons? Here is a straw proposal: by default, there is one other mapping created, and it collects all the mappings of all the classes that are presented to the context for marshaling or unmarshaling. That mapping does have an encoding URI. When the XMLTypeCreator looks at a .aegis.xml file, it uses that encoding URI to decide which, if any, of the mappings in the file to use.
