[xsd-users] Re: Polymorphism enhancements.

[Boris Kolpackov]

Hi Bill,

Bill Pringlemeir <bpringle at sympatico.ca> writes:

> On  9 Jan 2009, boris at codesynthesis.com wrote:
>
> > 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.
> 
> That is an excellent idea.  I can see that someone might wish to have
> derived xsi:string values.  However, the majority of people will just
> use one string type.  Having auto_ptr variants of strings is not
> useful 99% of the time.  It just generates extra code.

Right, and auto_ptr c-tors are only a part of it. Parsing and serialization
code for polymorphic objects is also more complex.


> I was lead to believe that the auto_ptr variants were to ease
> construction of composites.  Ie, you build base complex types and use
> the auto_ptr variants to build up the higher level aggregate.

That's one reason. And XSD will still generate auto_ptr versions
for arguments with "complex" types (i.e., types that have elements
or attributes).


> XSD must be using _clone and the auto_ptr variant to make this work 
> in 'setXxxx'?  

Yes, modifiers always use _clone(). 


> Would it be possible to detect the substition group to have this added
> automatically to the polymorphic type list?  Hmmm.  Actually that
> seems difficult as XSD has no idea that the base class is going to be
> extended.

The only tricky part is when you have a type and element defined in one
schema and then include/import that schema in another schema which defines
a substituting element. So when you compile the first schema without saying
that the type is polymorphic, there is not way for XSD to detect this. But,
when you compile the second schema and did not specify that the type in the
included schema is polymorphic, we will issue a warning. Other cases (e.g.,
single schema with substitution groups) can be handled auto-magically.
Overall, I think we will be able to make it quite robust.

Boris