Hi Adrian,
Thank you very much for the detailed diagram.
Going through your explanation, and looking at the last column
of the table, I think our assumption is implementing 'all' and 'choice'
constructs are justifiable.
In case of 'all' construct, if minOccures is zero, that means
the element can be optional. If it is nillable at the same time, and if
we do not send the nil value in serialization, one cannot find fault
with the resulting SOAP message as it does not violate the rules. Also,
if minOccures is zero and the element is nillable at the same time, if
the response send a xsi:nil="true" value, we still can deserialize that.
Hence we are not violating the rules again.
Handling of simultaneous minOccures="0" and nillable="true"
outside 'choice' and 'all' constructs is an area we need to explore a
bit more, as you have correctly pointed out.
> I think we need to consider how to support both
> simultaneously - though I understand the current design of generated
> stubs, etc. make it very hard to determine which one we're handling.
Agreed. This remains a TODO - good that this was brought to light in
dealing with 'choice' and 'all' constructs.
Thanks,
Samisa...
-----Original Message-----
From: Adrian Dick [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 19, 2005 6:30 PM
To: Apache AXIS C Developers List
Subject: Re: Handling Nillable elements which are wsdl choices
Hi,
While it may be the case that most people will not have nillable=true
and
minOccurs=0 simultaneously, it is permitted and they have different
effects
on the SOAP messages, and indeed potentially have very different meaning
to
a user application.
In the attached table, I've tried to show my understanding on how
nillable
and minOccurs map from the WSDL to the correct calls in generated stubs,
and in turn to the SOAP message.
(Embedded image moved to file: pic15926.jpg)
I hope this is of help. I think we need to consider how to support both
simultaneously - though I understand the current design of generated
stubs,
etc. make it very hard to determine which one we're handling.
_______________________________________
Adrian Dick ([EMAIL PROTECTED])
Samisa Abeysinghe <[EMAIL PROTECTED]> wrote on 19/05/2005
10:20:06:
> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> > 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.
> >
> > [EMAIL PROTECTED]
> >
> > Mob: 0714867441
> >
> >
> >
> >
> >
> >
