[xsd-users] RE: xsd bypasses customized types

Boris Kolpackov boris at codesynthesis.com
Tue Apr 13 12:07:18 EDT 2010


Hi Ray,

Ray Lischner <rlischner at proteuseng.com> writes:

> After further investigation, I think I better understand what is 
> happening. Suppose type A is a restriction of unsignedInt, and 
> type B is a restriction of A. When xsd generates constructors for 
> B, it suppresses the B::B(A&) constructor, and instead issues only 
> B::B(unsigned int), that is, because A has no required elements or
> attributes, B's immediate-base-class constructor is suppressed in 
> favor of B's ultimate-base-class constructor.

Yes, that's exactly what happens. And the reason for this is that
in such cases B::B(A&) does not add any new functionality since A
can be converted without loss of information to its base.


> This works fine until we customize type A. Somehow, we need to 
> tell xsd to favor the immediate-base-class constructor and 
> instead suppress the ultimate-base-class constructor. 

We can add some extra intelligence to this logic and avoid
suppressing the B(A&) c-tor if the hierarchy includes a
customized type. I don't think we can safely suppress
the other c-tor thought. Would having both c-tors work
for you?



More information about the xsd-users mailing list