[xsd-users] RE: xsd bypasses customized types

[Richard Cresswell]

Boris, I am having trouble using the patch you provided.  If I use the
--custom-type option for derived objects as you suggested below, xsd
throws a FrontendElements::Context::NoEntry exception (originating
from a call to FrontendElements::Context::get at
xsd/cxx/tree/name-processor.cxx:1018).

A simplified example:

<xsd:schema xmlns:test="test" xmlns:base="base" ... />

<xsd:import namespace="urn:base" schemaLocation="Base.xsd"/>

<xsd:complexType name="DerivedObject">
  <xsd:simpleContent>
    <xsd:extension base="base:BaseObject"/>
  </xsd:simpleContent>
</xsd:complexType>

<xsd:element name="test" type="test:DerivedObject"/>

I run xsd with the flag --custom_type BaseObject and receive the exception.

Is it possible to forward declare a custom type that is referenced but
not defined in the schema that is being compiled?  If I do not use
--custom-type the code in your patch has no way to know that
BaseObject is custom, causing it to build with the incorrect set of
constructors.

Thank you,

Richard Cresswell

On Wed, Apr 14, 2010 at 9:06 AM, Boris Kolpackov
<boris at codesynthesis.com> wrote:
> 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
>
>