[xsd-users] Excluding Schema Elements For the XSD Compiler (C++/Tree) To Ignore

[Boris Kolpackov]

Hi Alan,

Alan Amano <aamano1 at msn.com> writes:

> With C++/Tree, are there any ways to exclude certain simple/complex
> type elements so that the XSD compiler will ignore generating code
> for those types?  I have a very large schema file and it’s generating
> C++ source and header files that are huge, resulting in lengthy C++
> compile/link times downstream.  The schema file is a "baseline" and
> is shared among multiple users and I am only using a fraction of the
> type definitions in the schema file. Obviously, I can extract only
> those types I’m using into a separate schema file, but I’d rather
> not do this and risk getting out of sync from the baseline.  Unless
> I'm missing something, there weren’t any obvious XSD compiler
> options that I can see to accomplish this, so if you can recommend
> any methods or options to exclude types from the XSD compiler, I
> would appreciate it.

There is no automatic way to do this at the moment. The approach
that can (almost) work is to compile your schema in the file-per-
type mode. This will result in a separate set of C++ files
generated for each type defined in the schema. You can then pick
the ones that you need and discard the rest.

The reason I said it can almost work is because the parsing and
serialization functions for the root elements will be generated
in the file corresponding to the schema file which in turn includes
all the generated header files. Here is an example: Let's say we
have test.xsd which defines two types: 'foo' and 'bar'. It also
defines global element 'root' of type 'foo'. If we compile this
schema in the file-per-type mode, we will end up with the following
C++ files:

foo.hxx, foo.cxx  - class foo
bar.hxx, bar.cxx  - class bar
test.hxx, test.cxx - root() parsing/serialization functions

The test.hxx file will also have #include directives for foo.hxx
and bar.hxx. So if we remove bar.?xx because it is not used in
our application, we will get a compile error. There are two ways
to work around this: you can rename the test.?xx files and change
the test.hxx file to only include headers that are needed (you
can already generate parsing/serialization functions only for
certain root elements with the --root-element* options). This
should work since, presumably, root element names and their 
types don't change very often. Or you can drop the parsing and 
serialization functions altogther and call the parsing 
constructors and serialization operators directly. For this
you will need to perform your own XML-to-DOM and DOM-to-XML
conversions (see the 'performace' example for some sample code
that shows how to do this).

As for a fully-automatic way to do this, it would be quite easy
to implement for a single-file schemas. For example, you would
specify the root element(s) and the compiler will generate only
what's needed, directly and indirectly, by this root element(s)
(this will not work that easily for schemas that use polymorphism).

This, however, won't work for multi-file schemas in the file-per-
schema mode. When we compile included/imported schemas, we don't
know which types from it will be used by the including/importing
schemas. This can be worked-around if we require that when the
"minimal generated code" feature is on, all schemas are compiled
together. We already do something like this in XSD/e to support
polymorphism.

Boris