axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <samisa.abeysin...@gmail.com>
Subject Re: Handling Nillable elements which are wsdl choices
Date Thu, 19 May 2005 09:20:06 GMT
Does anyone has any concerns with the assumption that we have made
here? (The assumtion is that: for an element both nillable=true and it
being optinal cannot happen simultaneously)

Thanks,
Samisa...

On 5/18/05, Samisa Abeysinghe <SAbeysinghe@virtusa.com> wrote:
> 
> 
> 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="aRecord">
> 
>                                                 <xsd:all>
> 
>                                                            
> <xsd:element name="field1" type="xsd:string" nillable="true"/>
> 
>                                                            
> <xsd:element name="field2" type="xsd:string" fixed="field2Value"/>
> 
>                                                            
> <xsd:element name="field3" type="xsd:string" nillable="false"/>
> 
>                                                 </xsd:all>
> 
>                                     </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="aRecord">
> 
>                                                 <xsd:all>
> 
>                                                            
> <xsd:element name="field1" type="xsd:string" minOccurs="0" nillable="true"/>
> 
>                                                            
> <xsd:element name="field2" type="xsd:string" fixed="field2Value"/>
> 
>                                                            
> <xsd:element name="field3" type="xsd:string" nillable="false"/>
> 
>                                                 </xsd:all>
> 
>                                     </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 = false)
> 
> {
> 
>             if ( param == 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;
> 
>             }
> 
>  
> 
>             /* first serialize attributes if any*/
> 
>             pSZ->serialize( ">", 0);
> 
>  
> 
>             /* then serialize elements if any*/
> 
>             pSZ->serializeAsElement("NonChoiceIntValue",
> Axis_URI_ChoiceComplexType,
> (void*)&(param->NonChoiceIntValue), XSD_INT);
> 
>             
> 
> //……………………………………………………………………………………………………………………
> 
> //Following two elements are choice elements
> 
> // if the element is not NULL it goes to deserializer
> 
>  
> 
> 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);
> 
>             }
> 
>             
> 
> //……………………………………………………………………………………………………………………….
> 
> pSZ->serializeAsElement("NonChoiceStringValue",
> Axis_URI_ChoiceComplexType,
> (void*)(param->NonChoiceStringValue), XSD_STRING);
> 
>             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
> 
>  
> 
>  
> 
>
Mime
View raw message