[xsd-users] Re: Polymorphism enhancements. [was: Polymorphic problems.]

[Boris Kolpackov]

Hi Bill,

Bill Pringlemeir <bpringle at sympatico.ca> writes:

> 1. I have had some problems with constructors with a single arguement.
>    This will be used as conversion values by the compiler.  This is
>    especially problematic with simpleType extentions.  However, I have
>    found that customizing the simpleType with '--custom-type foo' was
>    often necessary, so I get the chance to use explicit in the
>    wrapper.  Users always have the option to do this.

I am not sure adding explicit to all single-argument c-tors is a 
good idea. Consider, for example, this fairly common situation:

<simpleType name="int_t">
  <restriction base="int"/>
</simpleType>

<xs:complexType name="type">
  <xs:sequence>
    <xs:element name="i" type="int_t"/>
  </xs:sequence>
</xs:complexType>

Right now one can write:

type t (10);

If we add explicit, then one will need to write:

type t (int_t (10));

We can always add an option (e.g., --generate-explicit) for this but
I am wondering how useful it will be.


> 2. In the polymorphism example, if person complex type and the
>    reference element are declared with 'abstract="true"', the same
>    code is generated no matter what.  It would be nice if the person
>    base had a pure virtual destructor and the type-factory-map.txx
>    supported base objects that cann't be created.  I believe that this
>    is possible as in instance documents we would have a different tag
>    name or xs:type attribute.  This allows a way to specify ABC in
>    schema notation, which seems to be the intent of 'abtract'.  This
>    would be most helpful in preventing mistakes where an ABC is
>    serialized.

Yes, we can do this. I've added it to the TODO list.


> 3. It is possible that a schema will have many similar data types with
>    the same defaults.  Would it be possible to use the same default
>    static instance in generated code.  Ie, if we have 20 "xs:int
>    default='0'" attributes, then twenty static elements are created.

Do you mean the same private value (in order to save space) or the 
same public accessors for these values?


> 4. Consider the schma below.  Processing with XSD defaults creates
>    only one constructor.  Add '--generate-base-ctor' and we have two.
>    Use '--generate-polymorphic' and we have *four* constructors.  This
>    is due to the auto_ptr interface needed by 'e3'.  Also, these
>    constructors are fairly expensive as the constructors set many of
>    the attributes to defaults.  Attributes are better (from a code
>    generation perspective) than elements because optional/default does
>    not require constructor arguments (passing all the values creates
>    more code).  Couldn't xsd generate a private 'setDefaults()' for
>    the derived class and call this within the body?

Yes, this is already on our TODO list. We plan to analyze the overhead
and see if adding a common init() function will help. 


> Alternatively, more control over the 'auto_ptr' mechanism that allows
> selective generation of constructors would help.

Not sure how this can be done. Specifying a set of c-tors to generate
for each type sounds too burdensome.

Thanks for all the suggestions!

Boris