[xsd-users] RE: xsd bypasses customized types

[Ray Lischner]

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.

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. Thus, the B constructor can take an A object as its from-base constructor, and we can construct an A with all its customizations.

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: xsd-users-bounces at codesynthesis.com [xsd-users-bounces at codesynthesis.com] On Behalf Of Ray Lischner [rlischner at proteuseng.com]
Sent: Monday, April 12, 2010 2:55 PM
To: xsd-users at codesynthesis.com
Cc: rcresswell at gmail.com
Subject: [xsd-users] xsd bypasses customized types

We are only now starting the transition to xsd 3.2 (just in time for 3.3!), and we are running into a small problem.

We customized a number of types. For example, we have a type CUnsignedInt, which is a restriction of an XML string. The customized type parses the string as a C-style integer and can treat the resulting object as an integer. When serialized to CDR, the customized type stores a binary integer instead of a string.

This worked fine in xsd 2.3, but causes problems in xsd 3.2.

Among the new features is that any string-based type gets some new constructors, including a default constructor. If a schema derives a type from a string-based type, the derived type get those same constructors.

Thus, if a schema derives a type from our CUnsignedInt type, that derived type gets a default constructor that invokes its base class's default constructor. We never defined a default constructor for CUnsignedInt, but we can add one to initialize the numeric value to zero.

More serious is that the code generation does not generate a from-base constructor, that is, one cannot construct an instance of the derived type from an instance of CUnsignedInt. This makes it considerably harder to construct an instance of the derived type from an integer. The developer would have to convert the integer to a string, and use the string as the argument to the constructor.

This violates the principles of the CUnsignedInt type, which looks and acts as an integer (from the developer's point of view). Only when serializing and parsing XML does CUnsignedInt reveal its string nature.

I don't mind it when new features change the way I need to write my customized types. I understand that I must accommodate my customizations. But this change breaks all the code that uses my customization. I cannot shield users from the change by modifying my customization.

So what can we do? At this time, we are considering modifying the xsd compiler to add a switch that would disable the new code that inhibits the from-base constructors and inserts the new string-based constructors. But is that the best solution? Thanks for the help.

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.