[xsd-users] cxx-tree Export Symbols Multiple Constants or Generate Def file via Namespace Map

[Laurence Davies]

Hi Boris,

Thank you for your valuable suggestions. 

> simply removing the parts of the GML that you don't need.

This is in itself a very large task!

> In fact, for GML 3.1.1 there was the "small profile" (3.1.1s). You may want to check if there is something like this for the version that you are using.

Do you mean the Simple Features profile? There are also the Point Profile and the CRSSupport Profiles.

Unfortunately, our schema uses some of the types not included in these profiles, specifically gml:AbstractCRS and some others, thus ruling out an off-the-shelf solution.

I noticed that there appears to be mention of a XSLT subset tool for GML in the specification and also on various websites, but it appears to be missing from any repository. Would you know anything about this tool?

Laurence Davies
____________________
Research Assistant in eGeodesy
CRC-SI, UNSW

________________________________________
From: Boris Kolpackov [boris at codesynthesis.com]
Sent: Wednesday, 8 October 2014 4:53 PM
To: Laurence Davies
Cc: xsd-users at codesynthesis.com
Subject: Re: [xsd-users] cxx-tree Export Symbols Multiple Constants or Generate Def file via Namespace Map

Hi Laurence,

Laurence Davies <laurence.davies at unsw.edu.au> writes:

> I have a very very large schema based on GML which I am extending with a
> smaller subset of types. I am creating a dll for reading/writing to this
> schema and I would like to have the option of exporting (via _dllspec or
> otherwise) *only* the subset I have created plus relevant dependencies in
> GML rather than *all* of GML. This is because the latter is enormous, and
> even with precompiled headers this vastly increases the complexity of the
> product I need to deliver.
>
> I see that --export-symbol= is the option to use for a blanket all-export
> or all-import switch, but is there a convenient way to export via
> namespace? I know this is far more complicated than it sounds due
> to dependencies but I believe VS10C++ will automatically traverse
> the inheritance/dependency tree to export all required symbols given
> that a particular leaf class type is exported.

You are correct about auto-exporting of base classes (which, BTW, is
a major source of trouble). There is, however, no auto-exporting of
classes that are merely "used", e.g., as data members or in the API.
So in this case you will have to somehow manually track down all the
used classes and export them, transitively. In case of GML, this will
be a monumental amount of work.

Also, keep in mind that GML is a polymorphic schema which means
certain classes might not be "used" (in the above sense) but still
might have to be exported since they will be created and returned
at runtime.

In the end, once you take all this into account, I am pretty sure
you will end up with exporting pretty much all of the GML.

You can also look at this problem in another way: if you are not
exporting certain classes, then why have them in the DLL in the
first place? So what you may want to consider is simply removing
the parts of the GML that you don't need. In fact, for GML 3.1.1
there was the "small profile" (3.1.1s). You may want to check if
there is something like this for the version that you are using.


> Alternatively, can XSD generate a .def file for this purpose?

No, XSD doesn't have this functionality.

Boris