Re: Implementing the rest of the DataReader and DataWriter

[Dain Sundstrom <da...@iq80.com>]

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

On Dec 27, 2007, at 12:32 PM, Benson Margulies wrote:

> The DataReader<T> interface has a method that takes an element  
> QName, an
> object, and a Class<?>.
>
> Aegis doesn't have an implementation ... yet. I'm working on it.
>
> In JAXB, the code respects the Class, and presumably throws up if the
> Object isn't consistent with that class.
>
> Unless I hear otherwise, I'll try to arrange the same fate for the  
> Aegis
> approach to the problem.
>
>
>

Re: Implementing the rest of the DataReader and DataWriter

[Dain Sundstrom <da...@iq80.com>]

On Jan 2, 2008, at 6:16 PM, Benson Margulies wrote:

>
> On Wed, 2008-01-02 at 18:02 -0800, Dain Sundstrom wrote:
>> On Jan 2, 2008, at 3:44 PM, Benson Margulies wrote:
>>
>>> 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?
>>
>> Yes
>
> This could only work at a safe distance from an actual web service.
>
> When a service uses Aegis to write things, it supplies element names
> from the parts. If you imagine a 'xsd2aegis' command, it would need  
> some
> way to annotate that {bloop}return is used as an element for
> {bleep}sometype. Maybe this is a red herring, and this is a case in
> which the reader knows what it expects. I suppose that making the read
> side use the element QName as a type QName is better than just  
> throwing
> an exception in the absence of xsi:type or orders from Jupiter.

In Aegis I normally only configure the exceptions to a rule, so I'd  
say the rule is the element name is the same as the type name.  If  
not, we configure the element name or mark a type as not a root  
element.  From the code perspective, element and type would be  
separate qnames in the class, so it only effects what a user has to  
enter.

-dain

Re: Implementing the rest of the DataReader and DataWriter

[Benson Margulies <bi...@gmail.com>]

On Wed, 2008-01-02 at 18:02 -0800, Dain Sundstrom wrote:
> On Jan 2, 2008, at 3:44 PM, Benson Margulies wrote:
> 
> > 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?
> 
> Yes

This could only work at a safe distance from an actual web service.

When a service uses Aegis to write things, it supplies element names
from the parts. If you imagine a 'xsd2aegis' command, it would need some
way to annotate that {bloop}return is used as an element for
{bleep}sometype. Maybe this is a red herring, and this is a case in
which the reader knows what it expects. I suppose that making the read
side use the element QName as a type QName is better than just throwing
an exception in the absence of xsi:type or orders from Jupiter.


> 
> -dain

Re: Implementing the rest of the DataReader and DataWriter

[Dain Sundstrom <da...@iq80.com>]

On Jan 2, 2008, at 3:44 PM, Benson Margulies wrote:

> 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?

Yes

-dain

Re: Implementing the rest of the DataReader and DataWriter

[Benson Margulies <bi...@gmail.com>]

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
> 
> 

Re: Implementing the rest of the DataReader and DataWriter

[Dain Sundstrom <da...@iq80.com>]

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

Re: Implementing the rest of the DataReader and DataWriter

[Benson Margulies <bi...@gmail.com>]

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?