Incorrect translation of complexType (D2007)

Hi!

The following complexType:
 <complexType name="IndicationStructureType">
  <choice>
   <sequence>
    <element ref="medicinecard:IndicationCode"/>
    <element ref="medicinecard:IndicationText"
minOccurs="0"/>
   </sequence>
   <element ref="medicinecard:IndicationFreeText"/>
  </choice>
 </complexType>

translates to the following code in Delphi:
  IndicationStructureType = class(TRemotable)
  private
    FIndicationCode: IndicationCode;
    FIndicationText: IndicationText;
    FIndicationText_Specified: boolean;
    FIndicationFreeText: IndicationFreeText;
    FIndicationFreeText_Specified: boolean;
    procedure SetIndicationText(Index: Integer; const AIndicationText: 
IndicationText);
    function  IndicationText_Specified(Index: Integer): boolean;
    procedure SetIndicationFreeText(Index: Integer; const 
AIndicationFreeText: IndicationFreeText);
    function  IndicationFreeText_Specified(Index: Integer): boolean;
  published
    property IndicationCode:     IndicationCode      Index (IS_REF) read 
FIndicationCode write FIndicationCode;
    property IndicationText:     IndicationText      Index (IS_OPTN or 
IS_REF) read FIndicationText write SetIndicationText stored 
IndicationText_Specified;
    property IndicationFreeText: IndicationFreeText  Index (IS_OPTN or 
IS_REF) read FIndicationFreeText write SetIndicationFreeText stored 
IndicationFreeText_Specified;
  end;

this is not correct since the property IndicationCode is only required if 
IndicationFreeText is not specified (inside a choice construct). The correct 
code should be something like this:
  IndicationStructureType = class(TRemotable)
  private
    FIndicationCode: IndicationCode;
    FIndicationCode_Specified: boolean;
    FIndicationText: IndicationText;
    FIndicationText_Specified: boolean;
    FIndicationFreeText: IndicationFreeText;
    FIndicationFreeText_Specified: boolean;
    procedure SetIndicationText(Index: Integer; const AIndicationText: 
IndicationText);
    function  IndicationText_Specified(Index: Integer): boolean;
    procedure SetIndicationFreeText(Index: Integer; const 
AIndicationFreeText: IndicationFreeText);
    function  IndicationFreeText_Specified(Index: Integer): boolean;
    function IndicationCode_Specified(const Index: Integer): Boolean;
    procedure SetIndicationCode(const Index: Integer; const Value: 
IndicationCode);
  published
    property IndicationCode:     IndicationCode      Index (IS_OPTN or 
IS_REF) read FIndicationCode write SetIndicationCode stored 
IndicationCode_Specified;
    property IndicationText:     IndicationText      Index (IS_OPTN or 
IS_REF) read FIndicationText write SetIndicationText stored 
IndicationText_Specified;
    property IndicationFreeText: IndicationFreeText  Index (IS_OPTN or 
IS_REF) read FIndicationFreeText write SetIndicationFreeText stored 
IndicationFreeText_Specified;
  end;

which is not even 100% correct...

Regards,
Erik 

Hello Erik,

Unfortunately this is a known problem that's tied to a deficiency of the
XMLIntf/TXMLDom interface: There's no way to retrieve the hierarchy of
nested compositors. The solution would be for the WSDL importer not to use
the XMLSchema binding we have but go directly to raw IXMLNode whenever we
encounter anything that's not a simple list of element within one compositor
type.

I'll probably take the easy route first and make all elements optional but
as you pointed out, that's not accurate. It gets worse when the compositor
node itself has minOccurs or maxOccurs attributes to flag its cardinality.

I wish I had better news but this is a good reminder to pick up this issue
with the XML team again.

Cheers,

Bruneau.

Hi!

I thing that you should go with my suggestion for now. At least it allows 
for valid XML code being generated. Without these changes this can otherwise 
be impossible (elements of a simple types will always generate output in XML 
if IS_REF is not specified).

Regards,
Erik

"Jean-Marie Babet" <bbabet@borland.com> skrev i en meddelelse 
news:479fe97d$1@newsgroups.borland.com...
> Hello Erik,
>
> Unfortunately this is a known problem that's tied to a deficiency of the
> XMLIntf/TXMLDom interface: There's no way to retrieve the hierarchy of
> nested compositors. The solution would be for the WSDL importer not to use
> the XMLSchema binding we have but go directly to raw IXMLNode whenever we
> encounter anything that's not a simple list of element within one 
> compositor
> type.
>
> I'll probably take the easy route first and make all elements optional but
> as you pointed out, that's not accurate. It gets worse when the compositor
> node itself has minOccurs or maxOccurs attributes to flag its cardinality.
>
> I wish I had better news but this is a good reminder to pick up this issue
> with the XML team again.
>
> Cheers,
>
> Bruneau.
>
> 

Hello,

> I thing that you should go with my suggestion for now. At least it allows
> for valid XML code being generated. Without these changes this can
otherwise
> be impossible (elements of a simple types will always generate output in
XML
> if IS_REF is not specified).

I suspect you meant IS_OPTN above. And yes, I agree that that approach would
be an acceptable workaround for now. I'll investigate. It leaves it up to
the user to know what properties to set.

Thank you!

Bruneau.