JAXB (xjc) is the tool that most closely produces the type of code that I will need for my project. I'm actually writing an EXI parser for an embedded system. That task has been already completed (manually) and since I'm ahead of schedule, I'd like to automate my work and have an independent implementation from what I did to verify the accuracy of my implementation. I tried Altova XML Spy and its generated code is unreadable and ugly. Liquid XML can't properly parse the schema, gSOAP produces errors with my schema because of the schema's complexity.
JAXB produces entirely readable and sensible code. It also appears to read the entire schema correctly. It is, by far, the best tool for doing this I've found yet.
The schemas I have represent a communication protocol, so the best representation of the data is in a C structs or C++ classes. I do not allow dynamic memory allocation when working in very small low powered embedded systems because of heap fragmentation, that makes Java unsuitable, and even malloc() and new() forbidden.
My specification also has additional restrictions placed on datatypes defined in the schema - so I have to modify the generated code regardless, so it must be readable and easy to maintain - and JAXB both being open source, well written, and able to read my schemas makes it the best choice for what I'm doing.
-Rich
On Wednesday, July 20, 2016 11:30 PM, Mirko Klemm <mirko_at_cm-klemm.de> wrote:
Hi Rich,
JAXB is a Java-specific API and technology.
For C++, there are a number of frameworks to address similar requirements as JAXB does, many of them part of larger frameworks, like Qt, gtk, Microsoft .Net, etc. - including XSD to C++ generation. It probably won't be necessary to write your own.
However, which of them are suitable for embedded development I cannot tell.
Btw. there are many embedded devices running Java out there, today maybe even more than those which run C++...
> <rich_wicks_at_yahoo.com>:
>
> Where do I get started?
>
> The Java code it produces is fine, but it's not suitable for an
> embedded project. I already have a perl script to convert it to C++,
> but I'd rather do this natively.