[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