[xsd-users] Obscure problem with inlines and custom types.

[Bill Pringlemeir]

If you have a custom type that converts from one type to another, this
can cause problems with the XSD generated inlines.

[primary.xsd]
   <xs:complexType name="Primary">

[composite.xsd]
   <xs:complexType name="Composite">
       <xs:sequence>
         <xs:element name="primary" type="Primary" />
   ...

[composite2.xsd]
   <xs:complexType name="Composite2">
      <xs:extension base="Composite">
   ...

[secondary.xsd]
   <xs:complexType name="Secondary">


Then 'CompositeWrapper.h'

   #include "secondary.h"
   class Composite : public Composite_base
   ...
   public:
      Secondary toSecondary();


Composite is a wrapped class.  Including any generated XSD headers
inside of the wrapper class when --hxx-epilogue is used can result in
missing 'ixx' files.  The end of composite.cxx will look like,

   #ifndef XSD_DONT_INCLUDE_INLINE

   #include "primary.ixx"

   #endif // XSD_DONT_INCLUDE_INLINE

   // Begin epilogue.
   //
   #include "CompositeWrapper.h"
   //
   // End epilogue.

A work around is to alway include the 'converted' class in the
composite file.  Ie, include secondary.xsd even though the schema
(composite.xsd) doesn't use it.  Otherwise, including composite2.h
will result in the secondary.ixx *not* being emitted and undefined
externals can result.

It seems possible that an additional XSD_IN_EPLIOGUE (along with
standard header gaurds) can be used to check for this condition and
warn the user.  Ie,

#ifndef SECONDARY_H
#define SECONDARY_H

#if defined(XSD_IN_EPLIOGUE) && defined(XSD_DONT_INCLUDE_INLINE)
#error Huston we have a problem.
#endif

...

Fwiw,
Bill Pringlemeir.