axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lefrancois, Carl" <>
Subject RE : abstract base type support
Date Fri, 18 Apr 2008 18:38:51 GMT
Hi Dimuthu,

Such a detailed email is promising.  If I understand correctly, the
functionality my project needs is already working (at least partly) in
the WSDL2Java tool?

My comments / ideas inline below:

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

Good.  I understand the tool is based on Java and I downloaded the java
source already when I started the project.  If I can make an acceptable
estimate for the work required, I may be asked to develop this piece.
Having dev support is a big plus, and even better is the idea that only
the translation to C needs to be done (XSLT transform on already
completed generic output from WSDL2Java)

> 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

For my application I have worked with the generated adb_*.c files so the
structure is already a bit familiar.

> Say type animal is extended by cat and dog types.
> so there will be adb objects with the names: adb_animal, adb_cat and
> ... To deserialize, create an object of the sub-type:
> 1. if (xml.get_attribute("xsi:type") == "cat") {
> 2.      var = adb_cat_create();
> 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*.
> And all the places of serialization and deserialization functions
signature where adb objects expects, should be changed to void*

This seems like the big problem: how to mimic the polymorphism used in
generating ADB objects in Java using standard C.  In Java, the
deserialisation routine can return an adb_cat object using an adb_animal
* but in C as you point out there is only void * which can easily cause

My first thought was rather to use the existing adb_animal.c class to
contain the derived-type attributes, and use the
adb_animal_cat_attribute_is_nil() approach when consuming deserialised
objects, rather than creating an adb_cat object and returning it as void
*.  The disadvantage with this may be greater file size (in my project
some .c files are >500kB!) but other than that it seems logical.  

E.g. to deserialize, create an object of the base-type and set sub-type

Adb_cat derives from adb_animal and extends with element IsDeclawed
defined with minOccurs = 1:

1. if (xml.get_attribute("xsi:type") == "cat") {
2. var = adb_animal_create();
3. var_set_isDeclawed( // value from IsDeclawed element )

And now client can consume like:
1. bool isDeclawed;
2. var = adb_animal_deserialize();
3. if (var.ConcreteType() == "cat") {
4. 	isDeclawed = adb_animal_get_IsDeclawed();

Likewise when serialising, the generated code can check 
1. if (concreteType == "cat") {
2. 	if (adb_animal_IsDeclawed_is_nil()) {
3.		Return error;

The question then becomes: from the output document created by
WSDL2Java, can the XSLT transform support creation of this code in the
adb_animal.c class?

I am not convinced which way is the best.  It seems we have different
ideas but I think you are better placed to know which is easiest to do
with an XSLT transformation of the current generated document.  I have
only heard of XSLT but never used it.

Have a good weekend


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

View raw message