Simple Types integration for DOC/LIT in C/C++ Stack

[Jean-Yves Baudy <jy...@free.fr>]

Susantha,

For my own opinion I think that we should involve more persons in this 
discussion. Simple types are very frequently used in a simple way. But 
they also can be more complex. Here an example :

     <element name="size" type="tns:simpleSize" />
     <simpleType name="simpleSize">
       <union>
         <simpleType>
           <restriction base="integer" />
         </simpleType>
         <simpleType>
           <restriction base="boolean" />
         </simpleType>
         <simpleType>
           <restriction base=string" />
         </simpleType>
       </union>
     </simpleType>

Where the XML can be :

   <size>1</size>
   <size>true</size>
   <size xsi:type='xsd:string'>1</size>


For this kind of declaration a class should be generated. This is 
probably why most of the stubs generation tooling produce classes for 
simpleTypes.

But your approach is also very useful for restriction on simpleTypes. 
The customer interface is very simple (only primitiv type méanipulation) 
and the generation process will be more simple to maintain.


Jean-Yves


 >Hi Jean-Yves
 >
 >> Hi Susantha,
 >>
 >> With your approach if we don't add any API to the runtime we need to
 >> consider the generation or not of classes/structures for the 
 >>simpleTypes.
 >>
 >> I think we need this generation to delegate the control to those 
 >>classes
 >> rather than to the generated classes of the "caller" complexType. An
 >
 >I agree. But I searched in all the wsdls I have for simpleType
 >declarations and I found that simpleType is used to basically have
 >restriction on it like enumerations, maxLength, minLength. These
 >restrictions are some checks to be done just before
 >serialization/deserialization. Please correct me if I am wrong.
 >
 >So what I suggest is not to create a type for a simpleType but create 
 >only
 >a function to check the restrictions and we have a typedef.
 >Ex1:
 >
 >   <s:simpleType name="aThing">
 >      <s:restriction base="s:string">
 >         <s:maxLength value="255"/>
 >     </s:restriction>
 >   </s:simpleType>
 >
 >we create
 >
 >typedef xsd_string aThing; //this is optional
 >
 >int Check_Restrictions_aThing(aThing* var)
 >{
 >  if (strlen(var)<255) return AXIS_RESTRICTION_OK;
 >  return AXIS_RESTRICTION_FAIL;
 >}
 >
 >Then the "caller" complex type will call Check_Restrictions_xxx >function
 >on each of its simpleType varibles to verify. Probably we have to >change
 >the API functions to add this function pointer passing capability.
 >Ex:
 >AddOutputParam(const AxisChar* pchName, void* pValue, XSDTYPE type)
 >to
 >AddOutputParam(const AxisChar* pchName, void* pValue, XSDTYPE type, >void*
 >pRestr_funct)
 >
 >But I am still thinking a lot about this design. Let me know what you 
 >think.
 >
 >
 >> other good reason for this is that a simpleType can be reused (so no
 >> code duplication).

Re: Simple Types integration for DOC/LIT in C/C++ Stack

[su...@opensource.lk]

Hi Jean-Yves,

> Susantha,
>
> For my own opinion I think that we should involve more persons in this
> discussion.

Definitely. Lets discuss how we handle restrictions, enumerations and
unions and do that.
extensions are working at the moment too. But its ok for C and we have to
review that for C++.

Thanks,

Susantha.

>Simple types are very frequently used in a simple way. But
> they also can be more complex. Here an example :
>
>      <element name="size" type="tns:simpleSize" />
>      <simpleType name="simpleSize">
>        <union>
>          <simpleType>
>            <restriction base="integer" />
>          </simpleType>
>          <simpleType>
>            <restriction base="boolean" />
>          </simpleType>
>          <simpleType>
>            <restriction base=string" />
>          </simpleType>
>        </union>
>      </simpleType>
>
> Where the XML can be :
>
>    <size>1</size>
>    <size>true</size>
>    <size xsi:type='xsd:string'>1</size>
>
>
> For this kind of declaration a class should be generated. This is
> probably why most of the stubs generation tooling produce classes for
> simpleTypes.
>
> But your approach is also very useful for restriction on simpleTypes.
> The customer interface is very simple (only primitiv type méanipulation)
> and the generation process will be more simple to maintain.
>
>
> Jean-Yves
>
>
>  >Hi Jean-Yves
>  >
>  >> Hi Susantha,
>  >>
>  >> With your approach if we don't add any API to the runtime we need to
>  >> consider the generation or not of classes/structures for the
>  >>simpleTypes.
>  >>
>  >> I think we need this generation to delegate the control to those
>  >>classes
>  >> rather than to the generated classes of the "caller" complexType. An
>  >
>  >I agree. But I searched in all the wsdls I have for simpleType
>  >declarations and I found that simpleType is used to basically have
>  >restriction on it like enumerations, maxLength, minLength. These
>  >restrictions are some checks to be done just before
>  >serialization/deserialization. Please correct me if I am wrong.
>  >
>  >So what I suggest is not to create a type for a simpleType but create
>  >only
>  >a function to check the restrictions and we have a typedef.
>  >Ex1:
>  >
>  >   <s:simpleType name="aThing">
>  >      <s:restriction base="s:string">
>  >         <s:maxLength value="255"/>
>  >     </s:restriction>
>  >   </s:simpleType>
>  >
>  >we create
>  >
>  >typedef xsd_string aThing; //this is optional
>  >
>  >int Check_Restrictions_aThing(aThing* var)
>  >{
>  >  if (strlen(var)<255) return AXIS_RESTRICTION_OK;
>  >  return AXIS_RESTRICTION_FAIL;
>  >}
>  >
>  >Then the "caller" complex type will call Check_Restrictions_xxx
> >function
>  >on each of its simpleType varibles to verify. Probably we have to
> >change
>  >the API functions to add this function pointer passing capability.
>  >Ex:
>  >AddOutputParam(const AxisChar* pchName, void* pValue, XSDTYPE type)
>  >to
>  >AddOutputParam(const AxisChar* pchName, void* pValue, XSDTYPE type,
> >void*
>  >pRestr_funct)
>  >
>  >But I am still thinking a lot about this design. Let me know what you
>  >think.
>  >
>  >
>  >> other good reason for this is that a simpleType can be reused (so no
>  >> code duplication).
>
>