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

[Jos van den Oever]

Hello Boris,

On Tuesday 08 August 2006 15:53, you wrote:
> > 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.

Even if the cost isn't high, it would be useful to have the namespaces as 
public constants in the parser. At the least this would avoid typos in the 
namespaces.

> > 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.
Ok, I'll do that, thanks.

> > 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.

Great.

> > 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

Seems 4.1 has nice improvements over 4.0.

> 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.

Ok, this is good to know, if this is the case, useage is much more acceptable.

> > 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

Great. This FLOSS exception ( i did  not read it properly before ) is a very 
good idea and a good way of bypassing the license incompatibilities. So if I 
understand correctly, it's ok to use as long as a significant amount of code 
under any of the FLOSS licenses is used. That's wonderful.

Thanks again for your answers,
Jos