axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dimuthu Gamage" <>
Subject Re: RE : abstract base type support
Date Fri, 18 Apr 2008 16:54:51 GMT
Hi Carl,
I have answered inline to your questions below.

On 4/18/08, Lefrancois, Carl <> wrote:
> Hi Dimuthu, list,
> I have some questions about adding support for abstract base types with complexContent
extension and restriction.
> For the application I am working on, it would be really useful to add this functionality
to the WSDL2C tool but before looking at the code to see how to go about doing this, I want
to find out if anyone has already worked on the problem and what they may have already discovered.
> Has there been any work done to try and get complex content extension / restriction supported
in WSDL2C?

As I mention in the early mail, WSDL2C fails only when xsi:type based
serialization and deserialization with complex content
extension/restriction. I have noted some of my ideas on how to
implement xsi:type based serialization/deserialization in the end of
this mail.

> If so, what aspects of the problem are difficult to design and/or lead to bugs in generated

I think we don't have much problem with the current designs, WSDL2Java
tool with the same design as WSDL2C has been successfully implemented
most of the schema constructs. But WSDL2C has some unimplemented
features which I believed to be very uncommon in practice. But
whenever user is interested in something, the developers tend to
implement it most of the time with the users support.

> Who are the main developers of the WSDL2C tool and is there a possibility of asking questions
about existing functionality / design decisions if I get the go-ahead to add this?

WSDL2C and WSDL2Java engines are based on the Axis2/Java codegen tool
which is maintained by the axis2/Java community
( There we have
several xslt (eXtensible Style sheet Transformation language) files
which are 'WSDL2C' specific, and they are mostly maintained by the
axis2/c community. Since most probably java tool is quit stable, we
only need to worry about the xslt is which generate the actual c code.
You can have an idea about these xsl files at here.[1][2] So you are
talking to the right list :)

Here is a little tip on how to implement xsi:type based serialization
and deserialization (just my idea).

currently each wsdl type/ element is mapped to an adb object. This adb
object contains
* structure keeping the object data
* getters/setters
* serialization( adb object to xml) and deserialization (xml to adb
object) functions. These function currently expect the exact
element/type as the name of the adb object.

Say type animal is extended by cat and dog types.

so there will be adb objects with the names: adb_animal, adb_cat and adb_dog.
With the current implementation

adb_animal_serialize only serialize whatever to xml say <animal>animal
specific parameters</animal>

if you go int to this function it logic will be something like (in pseudo code),

1. stream_write ("<animal>")
2. for each animal specific users_parameters as parameter
3. stream_write (" </animal>")

same way adb_animal_deserialize only identify the <animal> animal
specific parameters</animal> xml

So in a case we implement xsi:type based serialization/deserialization
the serialization would be changed to

1. stream_write ("<animal>")
2. call adb_animal_serialize_parameters (adb_object, user_parameters)
3. stream_write ("</animal>")

adb_animal_serialize_parameters function would be like following,

void adb_animal_serialize_parameters (adb_object, user_parameters ) {

1.  if( type_of(adb_object) == "cat") {
2.        set attribute ("xsi:type" , "cat");
3 .       adb_cat_serialize_parameters(adb_object, user_parameters);

4. if( type_of(adb_object) == "dog") {
5.        set attribute ("xsi:type" , "dog");
6.       adb_dog_serialize_parameters(adb_object, user_parameters);

7.  if( type_of(adb_object) == "animal) {
8.        set attribute ("xsi:type" , "animal");
9.        //execute the old algorithm
           for each animal specific users_parameters as parameter


Similarly adb_animal_deserialize_parameters should be introduced.

void adb_animal_deserialize_parameters (xml ) {

1. if (xml.get_attribute("xsi:type") == "cat") {
2.      var = adb_cat_create();
3.      adb_cat_deserialize_parameters(xml);
4. if (xml.get_attribute("xsi:type") == "dog") {
5.      var = adb_dog_create();
6.      adb_dog_deserialize_parameters(xml);
7   if (xml.get_attribute("xsi:type") == "animal") {
8         //the current algorithm in deserializing animal

Anyway implementing this in C is not much simple. The first thing it
doesn't support RTTI and it doesn't support type extension. you can't
put adb_cat object to where adb_animal is expected unless the
signature is changed to void*.

RTTI can be solved by generating the adb structures with their type
information like

struct adb_animal {
 .... ..
 axis2_char_t *whoami;

whenever adb_animal is created (adb_animal_create is called) it set
the whoami to "animal" which can be used to identify which type the
object is (in fact we can use a macro to returun the type). And all
the places of serialization and deserialization functions signature
where adb objects expects, should be changed to void* pointers.

Hope this tip is useful.



> Carl
> -----Message d'origine-----
> De : Dimuthu Gamage []
> Envoyé : mardi, avril 15, 2008 13:49
> À : Apache AXIS C User List
> Objet : Re: abstract base type support
> Hi Carl,
> Currently WSDL2C doesn't' support abstract base types with complexContent extension and
restriction which requires xsi:type attribute. But WSDL2C is tested with complexContent other
than abstract base types.
> In order to have this functionality, we may need to edit the serializing  and deserializing
logic inside the adb object corresponding to the base type. And we may need to provide an
API to inform the types of the element type explicitly.
> In a case you want to hack the generated code to have this functionality, my idea is
you better go through the adb_**_serialize and adb_**_deserialize functions for the abstract
> Thanks
> Dimuthu
> On Tue, Apr 15, 2008 at 8:13 PM, Lefrancois, Carl <>
> > Hello,
> >
> >  Can someone confirm that WSDL2C does not support WSDLs with abstract
> > base types?  The XML documents generated by my WSDL2C stubs have
> > validation errors  referring to missing xsi:type attributes. I think
> > the passage below from  the Databinding framework reference [1] says
> > that there is no support  for generation of xsi:type attributes yet:
> >
> >  Known Limitations
> >  ADB is meant to be a 'Simple' databinding framework and was not meant
> > to  compile all types of schemas. The following limitations are the
> > most  highlighted.  1. Complex Type Extensions and Restrictions.
> >
> >  If there is some way to enable generation of xsi:type attributes, can
> > someone kindly point it out? If this is not a supported feature, are
> > there any plans for it to be added later, or some effort already
> > underway?
> >
> >  Carl
> >  [1]
> >   _____
> >
> >  "Ce message est confidentiel, a l'usage exclusif du destinataire
> > ci-dessus et son contenu ne represente en aucun cas un engagement de
> > la  part de AXA, sauf en cas de stipulation expresse et par ecrit de
> > la part  de AXA. Toute publication, utilisation ou diffusion, meme
> > partielle,  doit etre autorisee prealablement. Si vous n'etes pas
> > destinataire de ce  message, merci d'en avertir immediatement
> > l'expediteur."
> >
> >  "This e-mail message is confidential, for the exclusive use of the
> > addressee and its contents shall not constitute a commitment by AXA,
> > except as otherwise specifically provided in writing by AXA. Any
> > unauthorized disclosure, use or dissemination, either whole or
> > partial,  is prohibited. If you are not the intended recipient of the
> > message,  please notify the sender immediately."
> >
> >  ---------------------------------------------------------------------
> >  To unsubscribe, e-mail:
> >  For additional commands, e-mail:
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message