[xsde-users] root element subset within a large schema/namespace

[Boris Kolpackov]

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