On Wed, 2008-01-02 at 11:52 -0800, Dain Sundstrom wrote: > One thing that would be helpful when using Aegis standalone or even > in CXF is if there was a JAXB facade. So, to use Aegis you could > just change the jaxb provider impl. Alternatively, if this is > difficult, we could make the user facing API more JAXBish. This > would help new users become adept at using Aegis much quicker. > > -dain
It seems to me that the lack of a 'root element' concept is a significant gap, here. Should we add something to the .aegis.xml format to allow a type to be a root element? From a plain API standpoint, the API I've been excreting doesn't look all that far removed from what you are asking for. DanD suggested that the time might have come to remix the TypeMapping and TypeMaappingRegistry. I can, I think, state some invariants about this: 1) Start by ignoring .aegis.xml files. In a live service, do we need more than one type mapping space? In particular, can a WSDL declare operations with disparate Encodings? If not, then we the 'encoding URI' becomes merely a parameter specifying which set of xsd type mappings we want to start with. 2) The boundary case between the 'data binding' and the service is the point at which the service TNS becomes known to the mapping system and becomes the namespace for types that don't declare some other namespace in their .aegis.xml file. 3) Now consider the 'uri' attribute in the .aegis.xml file. The idea is to allow multiple mappings. I'd propose that conditioning these by service TNS is a lot more useful than by 'encoding'. I'd like to rename that attribute to have a less confusing name. ... at least, less confusing to me. 4) At the level of the standalone API, the service TNS is the 'default namespace'. There is no reason for the default namespace to be a URI that happens to name a SOAP encoding, is there?
