axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From susan...@opensource.lk
Subject Re: Simple Types integration for DOC/LIT in C/C++ Stack
Date Fri, 12 Mar 2004 09:45:58 GMT
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).
>
>


Mime
View raw message