[xsd-users] Re: Polymorphism enhancements.

[Boris Kolpackov]

Hi Bill,

Thanks for the feedback. My comments are below.

Bill Pringlemeir <bpringle at sympatico.ca> writes:

> > We can always add an option (e.g., --generate-explicit) for this but
> > I am wondering how useful it will be.
> 
> That is a killer if you have 'operator' functionality in a wrapper
> with parameter overloading.  You end up getting ambiguous definitions.
> For example,
> 
> <xs:complexType name="quaterino">
>   <xs:sequence>
>     <xs:element name="oridinal" type="int_t"/>
>   </xs:sequence>
>   <xs:attribute name="i" type="int_t" default="0"/>
>   <xs:attribute name="j" type="int_t" default="0"/>
>   <xs:attribute name="k" type="int_t" default="0"/>
> </xs:complexType>
> 
> class  quaterino: public quaterino_base
> {
> public:
>    operator int();
> }
> quaterino operator+(const quaterino &, const quaterino&);
> quaterino operator+(const quaterino &, const quaterino&);
> quaterino operator+(const quaterino &, const quaterino&);

I am not sure I follow. Which definitions are ambiguous? Why do
you have three identical declarations of operator+ for quaterino?


> >> 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?
> 
> I meant the same private value to reduce code size.

That would be pretty hard to do and I don't think the gain will be
significant. 

We are also planning to change the way we handle default values. Right
now we parse the string representation of the default value as it appears 
in XML Schema at runtime. So for:

<attribute name="foo" type="int" default="123"/>

We generate something like:

int foo_default_value_ = traits<int>::parse ("123");

We are planning to change this to perform parsing at compile-time
so that we will generate:

int foo_default_value_ = 123;

For XML Schema types that are mapped to fundamental C++ types, such as
int, double, etc., we will probably eliminate the variable altogether
and return the literal directly. I think that will help your case.


> >> 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.
> 
> I am not sure which variant is used underneath by XSD generated code.
> However, with the 'base-ctor' option you can get four variants of
> constructors.  In some cases the only difference is an
> "xml_schema::string &" versus "std::auto_ptr<xml_schema::string>"
> parameter.  With this condition the 'base-ctor' will generate four
> versions.  The deep copy versions are useful to a user unless it is a
> complexType.
> 
> It becomes more painful when customizing these classes [there are four
> constructors to overload].  I was just wishing to turn off the
> 'auto_ptr' for a particular type (the class, not constructor
> parameters).  Did I miss something?  I don't think you can do this.

The auto_ptr versions for types like xml_schema::string are only
generated when polymorphism is enabled. This is done to allow 
polymorphic behavior for types derived from string even though,
in 99% of schemas, it is not needed.

While it is definitely possible to add an option that would disable
generation of the c-tor with auto_ptr arguments for a particular
type, I am trying to see if there is a better solution.

One idea that we have is to allow you to specify which hierarchies
in your object model actually need polymorphism. Normally a schema
would contain only a handful of types (usually derived from one or
two bases) that should be polymorphism-aware (that is, they can be
used in substitution groups and/or xsi:type). We can detect these 
types when substitution groups are involved but with xsi:type any
type can theoretically be used.

So we can provide an option, something like --polymorphic-base,
where you can specify root types for polymorphic hierarchies in
your schemas. Then the XSD compiler will generate polymorphism
support code (and c-tors with auto_ptr arguments) only for these
types and types that are derived from them. I believe this will
result in significant object code size reduction for most schemas.

What do you think?

Boris