[xsde-users] Using xsde in win32 to replace xsd

[Boris Kolpackov]

Hi Andre,

Moreira Andre <Andre.Moreira at helvar.com> writes:

> The codebase of the app I am working on shares the same codebase with
> win32 and ARM applications that we are developing. In the win32 codebase
> we have been using xsd successfully for the last year, but we now want
> to be able to use xmls in the ARM platform as well and xsde is the way
> to go.

Note that the choice between XSD and XSD/e is not really about
architectures but more whether the target is a resource-constrained,
mobile/embedded platform. These days ARM is used in all kinds of
general-purpose machines. For instance, nothing will prevent you
from using XSD on, say, ARM-based Raspberry Pi running full
GNU/Linux stack (e.g., Debian). It is a full-featured Linux
machine.


> Obviously we would like to use xsde in win32 as well in order to reduce
> dependencies and keep the codebase as simple as possible.  I was under the
> impression that xsde was an in place replacement for xsd without the
> dependencies,

No, that impression is incorrect. XSD/e object model/APIs are very
different compared to XSD.


> Is it possible for xsde to generate the files with parsing and
> serialization so that at least the created methods use the same
> signature?

Again, no, XSD/e object model is very different. You will have to
port your code.


> On final note. I am building the library with the /MDd option and
> I "ported" the cxx\hybrid\hello  example to a VS2013 solution that
> was using /MD. This caused a crash in this line doc_p.parse(argv[1]);
> 
> As soon as I realized an set the correct build option It worked fine,
> but it was a pain to realize why. It might help someone in the future
> to know that they need to double-check build options if something
> "weird" happens.

Yes, thanks for the note. The INSTALL file suggests that you copy
the exact options from your VC++ project to the config.nmake in
order to avoid "surprises" like this.

Boris