[xsde-users] root element subset within a large schema/namespace
Boris Kolpackov
boris at codesynthesis.com
Fri Dec 16 08:50:30 EST 2011
Hi Eric,
Eric Broadbent <eric.broadbent at csr.com> writes:
> Now that I'm using C++/Hybrid and the serializer code, the entire
> executable is quite large (40MB) and contains a lot of code that
> I don't really need, but I don't know exactly how to exclude all
> the unnecessary stuff. If I provide the main schema and it's
> dependent schemas as required, XSD/e will generate code for all
> the contained elements - even if I use the "--root-element" option.
>
> I suppose one way to deal with this is to generate my own copy of
> the schema which has only the target element/children that I want,
> and then filter the XML documents on input so that the only piece
> of the input stream that's given to the document_pimpl is the piece
> of interest.
Yes, that's probably the most precise method, though may require
quite a bit of manual work from your part.
> Are there other ways of dealing with this that don't require
> schema-trimming?
You can try the following approach:
1. Compile your schema with the --file-per-type option. This will
result in hundreds (if not thousands) of source files, one for
each schema type.
2. Compile them and put them into a static library (.a on Linux/UNIX,
.lib on Windows). The compilation time will probably be atrocious,
much, much longer than without the --file-per-type option. If you
can, try to use the -j GNU make option to compile in parallel.
3. You cannot use the generated aggregates with this approach. Instead,
you will need to assemble the parser yourself, as you did for the
C++/Parser mapping, and not setting the parsers in which you are
not interested in. One thing that you can do to help with this
task is to generate aggregates for top-level types in which you
are interested in instead of the root element (use the --root-type
option). For example, if you have something like this:
<xsd:complexType name="root_t">
<xsd:sequence>
<xsd:element name="foo" type="foo_t"/>
<xsd:element name="bar" type="bar_t"/>
<xsd:element name="baz" type="baz_t"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="root" type="root_t"/>
And you are only interested in the foo and baz elements, then instead
of generating an aggregate for the root element, you generate aggregates
for foo_t and baz_t, and then assemble the root_t parser using these
two aggregates.
4. Link your application using the static library created on step 2. The
idea here is to take advantage of the static linker behavior, which
ignores object files in the archive that don't satisfy any symbols
in the resulting executable. While you will still end up with all
the pskel/sskel files in the executable, the pimpl/simpl files for
unused content will be ignored. When comparing executable sizes
between the two approaches, it is a good idea to compile everything
with optimization.
Boris
More information about the xsde-users
mailing list