axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: AXIOM and data binding [Re: [Axis2] AXIOM goals
Date Tue, 16 Nov 2004 02:06:44 GMT
Sanjiva Weerawarana wrote:

>Dude, prefix your messages with [Axis2] ;-).
>  
>
for my filter it is enough if axis2 is in subject as it is common that 
when you reply you get "Re: [Axis2] ..." so otherwise i would miss all 
replies ;-)

anyway i think we may need a separate mailing list ...

alek

>----- Original Message ----- 
>From: "Aleksander Slominski" <aslom@cs.indiana.edu>
>To: <axis-dev@ws.apache.org>
>Sent: Monday, November 15, 2004 11:10 PM
>Subject: AXIOM and data binding [Re: [Axis2] AXIOM goals
>
>
>  
>
>>Sanjiva Weerawarana wrote:
>>
>>    
>>
>>>"Aleksander Slominski" <aslom@cs.indiana.edu> writes:
>>> 
>>>
>>>      
>>>
>>>>* AXIOM API is designed to support pluggable XML transformations
>>>>(JavaBeans2XML, XSD with JaxMe/JAXB, Castor, XmlBeans, RelaxNG, ...)
>>>>discussed in http://nagoya.apache.org/jira/browse/AXIS-1498
>>>>   
>>>>
>>>>        
>>>>
>>>I can't read AXIS-1498 right now (offline ATM) but data binding is NOT
>>>part of AXIOM. 
>>>
>>>      
>>>
>>what i mean by it is "designed to support" is that doing data binding 
>>should be make easier by making AXIOM API works well with any data 
>>binding framework.
>>
>>    
>>
>>>In fact data binding is layered into the engine so that
>>>all of Axis2 can run without any data binding and with the app accessing
>>>the OM directly (maybe via something like JXPath layered on).
>>> 
>>>
>>>      
>>>
>>yes so AXIOM API must be designed (or changed when needed) so to support 
>>such access.
>>
>>    
>>
>>>The point is that providers which have Java object-ified views of
>>>the incoming XML blob is not the only way to implement a service. For
>>>example, the service may be one or more XSLT scripts.
>>> 
>>>
>>>      
>>>
>>yes - i think it would be very good for doc/literal kind of services and 
>>AXIOM should make it easy and not hard to implement such service.
>>
>>alek
>>
>>-- 
>>The best way to predict the future is to invent it - Alan Kay
>>
>>
>>    
>>


-- 
The best way to predict the future is to invent it - Alan Kay


Mime
View raw message