[xsd-users] Re: using xsd in community applications

[Boris Kolpackov]

Hi Jos,

I've CC'ed xsd-users back in; someone might find this information useful.

Jos van den Oever <jvdoever at gmail.com> writes:

> I thinks this example:
>
> ...
>
> should be in the manual.

Added to my TODO list, thanks.


> What i meant was not to disable serialization entirely but to have
> e.g. only iostream serialization. I don't know how this will affect
> code source though.

The core of the serialization (and parsing) uses Xerces streams.
Everything else are just thin wrappers around that. I also think
that most people will prefer to use either URL or std stream for
i/o.


> There may be other possible gains. E.g. adding a
> constant for each string esp. namespace URL. There pop up in a lot of
> places. It would be nice if one could just refer to a constant there.

I also thought string constants will have significant impact on code
size. Then I performed detailed analysis of the object code with nm.
As it turns out, the string constant size is negligible compared to
the text (executable code) size.


> That's true, it's almost 7k in headers. Thats very doable. I didn't
> actually check the header sizes. They're very small. Amazing concept
> by the way, header-only library.

You can further reduce the libxsd size by removing the C++/Parser
mapping runtime (the 'parser' directory) since you are not using it.


> Maybe you could headers to fit an xsd on demand. Just include what's
> required.

It is already done like this. Each optional feature (e.g., serialization)
has a set of headers that are only included if the feature is used.


> I don't know exactly where the size comes from, but the simple example
> above gives a binary of 123k (-Os) which is quite large.

I did a quick test on the hello example from the distribution. I used
g++ 4.1 on a 64 bit machine. Here are the results:

92846  -Os
84396  -O3
60848  stripped -O3

I also examined the symbols with nm (nm -C --print-size --sort-size).
Most of the code comes from things like exceptions, internal helper
functions, etc. All of them are a once-off upfront cost. In other
words, no matter how big is your schema, you will have a fixed
amount of this service code.


> Another question: is it possible to use XSD under an LGPL license. I'm
> using it in a daemon now, so that's on problem. If I'd like to
> communicate in XML with LGPL client libraries or if e.g. KDE would
> want to use xsd too, LGPL would be required.
> I'm guessing you won't allow this, which is of course fine, just asking.

You can use the generated code and runtime in pretty much any open-source
projects (including LGPL-licensed ones). The compiler itself is GPL-only,
though. See the FLOSS exception on the XSD licensing page[1] for more
information.

[1] http://codesynthesis.com/products/xsd/license.xhtml


hth,
-boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: Digital signature
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060808/91fcb5b2/attachment.pgp