Return-Path: Delivered-To: apmail-ws-axis-c-dev-archive@www.apache.org Received: (qmail 19974 invoked from network); 18 May 2005 05:39:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 18 May 2005 05:39:36 -0000 Received: (qmail 35470 invoked by uid 500); 18 May 2005 03:50:50 -0000 Delivered-To: apmail-ws-axis-c-dev-archive@ws.apache.org Received: (qmail 35341 invoked by uid 500); 18 May 2005 03:50:47 -0000 Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: "Apache AXIS C Developers List" Reply-To: "Apache AXIS C Developers List" Delivered-To: mailing list axis-c-dev@ws.apache.org Received: (qmail 35283 invoked by uid 99); 18 May 2005 03:50:46 -0000 X-ASF-Spam-Status: No, hits=0.4 required=10.0 tests=FORGED_RCVD_HELO,HTML_MESSAGE,HTML_TEXT_AFTER_BODY,HTML_TEXT_AFTER_HTML X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from smtp.erunway.com (HELO mailhost.virtusa.com) (12.40.51.197) by apache.org (qpsmtpd/0.28) with ESMTP; Tue, 17 May 2005 20:50:33 -0700 Received: from cs-mailsvr.Virtusa.com ([10.2.1.11]unverified) by mailhost.virtusa.com with InterScan Messaging Security Suite; Tue, 17 May 2005 23:31:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55B5A.88B160FC" Subject: RE: Handling Nillable elements which are wsdl choices Date: Wed, 18 May 2005 09:34:44 +0600 Message-ID: <403DD48EAE182940B89ECEAFE03F969002D16690@cs-mailsvr.Virtusa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Handling Nillable elements which are wsdl choices Thread-Index: AcVaznS9N+Q0DqWCSc+ZVKWbTwCPfAAiJiSA From: "Samisa Abeysinghe" To: "Apache AXIS C Developers List" X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. ------_=_NextPart_001_01C55B5A.88B160FC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let me clear the air a bit more here. =20 In the way we have implemented both 'choice' and 'all' constructs, we use C++ NULL value to check if some field is optional in serialization. In other words, if a field is optional as per the WSDL definition, and if the C++ class attribute is NULL, then we simply do not deserialize the value. =20 However, this assumption seems to fail in case of 'nillable' values. The current implementation works with nillable values correctly for 'all' and 'choice' constructs as far as a given attribute (I mean a data member) is not both nillable and optional at the same time. (To my understanding, in practice, this is unlikely to happen, but if it happens the implementation would fail) =20 Let me give a practicle example with the 'all' construct. In the test WSDL ComplexTypeAll.wsdl used for the test NilValuesTest we have: =20 Going by the 'all' construct definition, since minOccurs is not mentioned, it is a must that all fields MUST appear in the aRecord and out of those field1 could be NULL. =20 However, if I change the definition to the following we run into trouble: Now, field1 is both optional and niallable. As per the current implementation, if field1 is set to (C++) NULL, we would deem that it is optional and would not sterilize it now. However, as the element is nillable, we could have serialized the element as a null (empty) element, but the current implementation does not do that. Is this a problem? =20 =20 Thanks, Samisa... =20 -----Original Message----- From: Dushshantha Chandradasa [mailto:dchandradasa@virtusa.com]=20 Sent: Tuesday, May 17, 2005 4:52 PM To: Apache AXIS C Developers List Subject: Handling Nillable elements which are wsdl choices =20 Hi All, =20 I implemented the support for 'choice' WSDL construct in Axis C++ . According to our design, generated stub level classes serialize the choice elements in the following way. =20 int Axis_Serialize_ChoiceComplexType(ChoiceComplexType* param, IWrapperSoapSerializer* pSZ, bool bArray =3D false) { if ( param =3D=3D NULL ) { /* TODO : may need to check nillable value - Now done*/ pSZ->serializeAsAttribute( "xsi:nil", 0, (void*)&(xsd_boolean_true), XSD_BOOLEAN); pSZ->serialize( ">", NULL); return AXIS_SUCCESS; } =20 /* first serialize attributes if any*/ pSZ->serialize( ">", 0); =20 /* then serialize elements if any*/ pSZ->serializeAsElement("NonChoiceIntValue", Axis_URI_ChoiceComplexType, (void*)&(param->NonChoiceIntValue), XSD_INT); =20 //...................................................................... .............................................................. //Following two elements are choice elements // if the element is not NULL it goes to deserializer =20 if(param->IntValue) { pSZ->serializeAsElement("IntValue", Axis_URI_ChoiceComplexType, (void*)(param->IntValue), XSD_INT); } else if(param->StringValue) { pSZ->serializeAsElement("StringValue", Axis_URI_ChoiceComplexType, (void*)(param->StringValue), XSD_STRING); } =20 //...................................................................... .................................................................. pSZ->serializeAsElement("NonChoiceStringValue", Axis_URI_ChoiceComplexType, (void*)(param->NonChoiceStringValue), XSD_STRING); return AXIS_SUCCESS; } =20 =20 But if the choice element is a nillable one and its value is set to NULL, then the above logic will fail.=20 =20 Any thoughts on this?? =20 Regards, =20 Marcus Dushshantha Chandradasa Associate Software Engineer Virtusa (Pvt) Ltd. dchandradasa@virtusa.com Mob: 0714867441 =20 =20 =20 ------_=_NextPart_001_01C55B5A.88B160FC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Let me clear the air a bit more = here.

 

In the way we have implemented both = ‘choice’ and ‘all’ constructs, we use C++ NULL value to check if some = field is optional in serialization. In other words, if a field is optional as = per the WSDL definition, and if the C++ class attribute is NULL, then we simply = do not deserialize the = value.

 

However, this assumption seems to = fail in case of ‘nillable’ values. The = current implementation works with nillable values = correctly for ‘all’ and ‘choice’ constructs as far as a given = attribute (I mean a data member) is not both nillable = and optional at the same time. (To my understanding, in practice, this is = unlikely to happen, but if it happens the implementation would = fail)

 

Let me give a practicle example with the ‘all’ construct. In the test WSDL ComplexTypeAll.wsdl  used = for the test NilValuesTest we = have:

 

<xsd:complexType name=3D"aRecord">

        = ;            =             &= nbsp;           &n= bsp;   <xsd:all>

        = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   <xsd:element name=3D"field1" type=3D"xsd:string" nillable=3D"true"/><= /font>

        = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   <xsd:element name=3D"field2" type=3D"xsd:string" fixed=3D"field2Value"/>

        = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   <xsd:element name=3D"field3" type=3D"xsd:string" nillable=3D"false"/>=

        = ;            =             &= nbsp;           &n= bsp;   </xsd:all>

        = ;            =             &= nbsp;   </xsd:complexType>

=

Going by the ‘all’ = construct definition, since minOccursis not mentioned, it is a must that all fields MUST appear in the aRecord and out of those field1 could be NULL.

 

However, if I change the definition = to the following we run into trouble:

<xsd:complexType name=3D"aRecord">

        = ;            =             &= nbsp;           &n= bsp;   <xsd:all>

        = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   <xsd:element name=3D"field1" type=3D"xsd:string" minOccurs=3D”0” nillable=3D"true"/><= /font>

        = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   <xsd:element name=3D"field2" type=3D"xsd:string" fixed=3D"field2Value"/>

        = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   <xsd:element name=3D"field3" type=3D"xsd:string" nillable=3D"false"/>=

        = ;            =             &= nbsp;           &n= bsp;   </xsd:all>

        = ;            =             &= nbsp;   </xsd:complexType>

=

Now, field1 is both optional and = niallable. As per the current implementation, if = field1 is set to (C++) NULL, we would deem that it is optional and would not = sterilize it now. However, as the element is nillable, we = could have serialized the element as a null (empty) element, but the current implementation does not do that. Is this a = problem?

 

 

Thanks,

=

Samisa…

 

-----Original = Message-----
From: = Dushshantha Chandradasa = [mailto:dchandradasa@virtusa.com]
Sent: Tuesday, May 17, 2005 = 4:52 PM
To: Apache AXIS C = Developers List
Subject: Handling = Nillable elements which are wsdl choices

 

Hi = All,

 

I implemented the support = for ‘choice’ WSDL construct in Axis C++ . According to our design,  generated stub level classes serialize the choice elements = in the following way.

 

int Axis_Serialize_ChoiceComplexType(ChoiceComplexType* param, IWrapperSoapSerializer* pSZ, bool bArray =3D = false)

{

    &nbs= p;       if ( param =3D=3D NULL )

    &nbs= p;       {

    &nbs= p;        /* TODO : may need to check nillable value - Now = done*/

    &nbs= p;            = ;       pSZ->serializeAsAttribute( "xsi:nil", 0, = (void*)&(xsd_boolean_true), XSD_BOOLEAN);

    &nbs= p;            = ;       pSZ->serialize( ">", NULL);

    &nbs= p;            = ;       return AXIS_SUCCESS;

    &nbs= p;       }

 

    &nbs= p;       /* first serialize attributes if any*/

    &nbs= p;       pSZ->serialize( ">", 0);

 

    &nbs= p;       /* then serialize elements if any*/

    &nbs= p;       pSZ->serializeAsElement("NonChoiceIntValue", Axis_URI_ChoiceComplexType, (void*)&(param->NonChoiceIntValue), XSD_INT);

    &nbs= p;      

//………̷= 0;…………………………&= #8230;………………………R= 30;…………………………= ………………………

//Following two elements are choice elements

// if = the element is not NULL it goes to deserializer

 

if(param->IntValue)<= /o:p>

    &nbs= p;       {

    &nbs= p;            = ;       pSZ->serializeAsElement("IntValue", = Axis_URI_ChoiceComplexType, (void*)(param->IntValue), XSD_INT);

    &nbs= p;       }

    &nbs= p;       else if(param->StringValue)

    &nbs= p;       {

    &nbs= p;            = ;       pSZ->serializeAsElement("StringValue", = Axis_URI_ChoiceComplexType, (void*)(param->StringValue), = XSD_STRING);

    &nbs= p;       }

    &nbs= p;      

//………̷= 0;…………………………&= #8230;………………………R= 30;…………………………= ………………………….

pSZ->serializeAsElement(&= quot;NonChoiceStringValue", Axis_URI_ChoiceComplexType, (void*)(param->NonChoiceStringValue), XSD_STRING);

    &nbs= p;       return AXIS_SUCCESS;

}

 

 

But if the choice element = is a nillable one and its value is set to NULL, then the above logic will = fail.

 

Any thoughts on = this??

 

Regards,

 

Marcus = Dushshantha Chandradasa

Associate  Software = Engineer

Virtusa (Pvt) = Ltd.

dchandradasa@virtusa.com

Mob:  = 0714867441

 

 

 

=00 ------_=_NextPart_001_01C55B5A.88B160FC--