Here's the question. Given an XML message, how do you unmarshal it if it
lacks an xsi:type? If you have a list of root elements, then you know
their types.
If you don't have a list of root elements, what QNames do you associate
with the types? Do you assume that, if a class has schema type QName
{aaaa}b that it also likes to be a root element names {aaaa}b?
On Wed, 2008-01-02 at 14:32 -0800, Dain Sundstrom wrote:
> On Jan 2, 2008, at 12:15 PM, Benson Margulies wrote:
>
> >
> > 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?
>
> I find the root element concept in jaxb to be annoying. Unless I'm
> missing something big, it seem to be there only for java to schema
> conversion. If that is the case, why not make all elements root-able?
>
> > 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?
>
> I still don't understand this part of the code. Is this something we
> will need if we want a service to be exposed with soap encoding for
> legacy client and doc lit for modern clients?
>
> -dain
>
>
