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

Bill Pringlemeir bpringle at sympatico.ca
Thu Dec 4 13:45:04 EST 2008


On  4 Dec 2008, boris at codesynthesis.com wrote:

> I've come up with a work around for this problem which makes the
> test run as expected on AIX. The changes are only to libxsd so
> you can apply them to your copy of XSD 3.2.0:

> http://codesynthesis.com/~boris/tmp/xsd-3.2.0-xlc-aix.patch

Thanks Boris.  This seems to resolve all of our problems.  

I have some suggestions (mainly for polymorphism code generation).

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.

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.

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.

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?  Alternatively,
   more control over the 'auto_ptr' mechanism that allows selective
   generation of constructors would help.

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:simpleType name="fromSimple">
    <xs:restriction base="xs:long"/>
  </xs:simpleType>


  <xs:complexType name="attrOnly">
    <xs:sequence>
      <xs:element name="e1" type="xs:int"/>
    </xs:sequence>
    <xs:attribute name="a1" type="fromSimple" default="0" />
    <xs:attribute name="a2" type="xs:dateTime" default="1970-01-01T00:00:00" />
    <xs:attribute name="a3" type="xs:string" default="" />
    <xs:attribute name="a4" type="xs:byte" default="0" />
    <xs:attribute name="a5" type="xs:float" default="0.0" />
  </xs:complexType>

  <xs:complexType name="derived">
    <xs:complexContent>
      <xs:extension base="attrOnly">
      <xs:sequence>
        <xs:element name="e2" type="xs:long"/>
          <xs:element name="e3" type="xs:dateTime"/>
          </xs:sequence>
          <xs:attribute name="a6" type="fromSimple" default="0" />
          <xs:attribute name="a7" type="xs:dateTime" default="1970-01-01T00:00:00" />
          <xs:attribute name="a8" type="xs:string" default="" />
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

</xs:schema>
<!-- -*- mode: xml;-*- -->

Thanks once again!
Bill Pringlemeir.

-- 
I never did give anybody hell.  I just told the truth and they thought
it was hell. - Harry S. Truman




More information about the xsd-users mailing list