[xsd-users] RE: xsd bypasses customized types

[Ray Lischner]

One difficulty is that we have many schemas. Type A may be customized in schema B, and type C is customized in schema D, so when compiling schema E, which contains types that extend A and C, one must know about all the customizations and pass appropriate command line arguments to xsd. This puts quite a burden on the person writing schema E.

Ray Lischner,
Senior Member of Technical Staff
133 National Business Pkwy, Ste 150     t. 443.539.3448
Annapolis Junction, MD 20701                c. 410.854.5170
rlischner at proteuseng.com                     f. 443.539.3370

This electronic message and any files transmitted with it contain information
which may be privileged and/or proprietary. The information is intended for use
solely by the intended recipient(s). If you are not the intended recipient, be
aware that any disclosure, copying, distribution or use of this information is
prohibited. If you have received this electronic message in error, please advise
the sender by reply email or by telephone (443.539.3400) and delete the message.
________________________________________
From: Boris Kolpackov [boris at codesynthesis.com]
Sent: Tuesday, April 13, 2010 12:07 PM
To: Ray Lischner
Cc: xsd-users at codesynthesis.com
Subject: Re: [xsd-users] RE: xsd bypasses customized types

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?