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

[Eric Broadbent]

Hi Boris,
I appreciate your helpful reply.
Compiling the generated code will reveal the dependencies on a reduced schema (i.e. when other schemas are required there will be an include), so I am going to try editing the schema first
It's not simple, but I believe it's less work than the single-file-per-element method.
Thanks again for your help with this.

-Eric

On Dec 16, 2011, at 8:50 AM, Boris Kolpackov wrote:

> 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
> 
> 
> To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== .



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog