[xsd-users] RE: xsd bypasses customized types

[Ray Lischner]

I think the custom type approach will work. We can create a single, shared options file that lists all of our custom types.

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: Wednesday, April 14, 2010 9:06 AM
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:

> 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.

Yes, that's unfortunately the case. The original idea was to have
truly separate compilation of schemas but the reality proved we
are fighting a loosing battle. For example, in XSD 3.3.0 there is a
new option that allows one to specify which types are polymorphic
to reduce the generated code size. If the base is in schema B and
derived is in schema D, then one has to specify that the base is
polymorphic while compiling schema D. There is no other way to
figure this out.

The recommended way to handle this is to create an options file
which contains the --custom-type options for a specific set of
schemas (i.e., a set of schemas corresponding to an XML vocabulary).
Then when compiling other schemas that use this set of schemas
one can add the options file to the XSD command line.

In this particular situation I don't see any good alternatives to
using the custom type information to decide not to suppress the
c-tor. Always generating the c-tor is not an option since in
99.9% of cases it will result in unnecessary code bloat. Having
a special option to selectively generate the c-tor for certain
types seems to require an even greater amount of work from your
side.

Let me know if the custom type approach will be acceptable or
if you have any other ideas.

Boris