[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