cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Implementing the rest of the DataReader and DataWriter
Date Wed, 02 Jan 2008 23:44:48 GMT
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
> 
> 


Mime
View raw message