Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v753)
In-Reply-To: <1199304917.12647.11.camel@bim-1330.basistech.net>
References: <1198725096.17295.53.camel@bim-1330.basistech.net>
 <4773F907.6060004@mulesource.com>
 <1198787539.6749.13.camel@bim-1330.basistech.net>
 <80ADE290-0468-41F7-AF7E-030D0DE03DE7@iq80.com>
 <1199304917.12647.11.camel@bim-1330.basistech.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <40E2D324-3867-472C-AA90-3F2B2B757A14@iq80.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dain@iq80.com>
Subject: Re: Implementing the rest of the DataReader and DataWriter
Date: Wed, 2 Jan 2008 14:32:11 -0800
To: cxf-dev@incubator.apache.org

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