Xsd-parser - Code generator for XML schemas

announcements
1

Hey guys,

I just wanted to share my latest project with you. It's a code generator for XML schema called xsd-parser. Feel free to have a look at the code. Any kind of feedback is welcome :slight_smile:

https://crates.io/crates/xsd-parser

Greetings, Bergmann89.

5 Likes
2

Awesome. Rust really needs better tools for this area.

1 Like
3

Hey guys,

I've just released a new version with some major improvements to the generator. Thanks to all that gave some feedback and contributed to the project :slight_smile:

4

Hey guys,

I published a new version v0.3.0 of my xsd-parser a couple of minutes ago. Beside other fixes and improvements the following points were the main changes for this version:

  • Complete refactoring of the code generator, to simplify the code of the generator itself, as well as the generated code
  • Improved support for de-/serialization using quick_xml for the generated code
  • Custom defined names for the generated types (useful for naming conflicts inside the generated code)
  • More tests for the different features of the tool and additional tests for a small selection of well known XML schemas
  • General bug fixes and improvements

Feel free to have a look. I would love to get some feedback :slight_smile:

5

How do you deal with inheritance? Do you emit enums for all options? Do you use a trees of enums? Do you use traits?

I saw this code xsd-parser/tests/feature/extension_base at 2eea21c4f32ba560c2af566078b9899461578e2a · Bergmann89/xsd-parser

It seems properties from parent are projected into the child. I was wondering how assignment would work in case of a child being assign to a field of parent type and also downcasting when receiving polymorphic data.

I was wrestling with this in my projects and settled for a complex story as the hierarchy was enormous - little bit of enums, lots of traits, little bit of dynamic types (Maps).

6

Hey @noclue :slight_smile:

as far as I understand extending (or restricting) a type does not necessarily mean to inherit the extended type from the base type (in case of the restriction this is even wrong). Such types will be renderer as separate type, having the same subset of fields as the base type.

Downcasting one type to another type is only needed for dynamic/abstract types and/or for substitution groups. For them I will generate a suitable trait, that is then implemented by the types of that group. You can find an example for substitution groups here.

The trait does currently not have any methods, it's just used to keep track of the types/groups. It's basically a more advanced core::any::Any. As a possible extension of the tool I could implement getters and setters for the different values of a particular substitution group if you need something like that. With the current implementation you have to check the type id of the actual stored type and cast it manually.

1 Like
7

I'm excited to share that, thanks to your support, the project has reached a stable state and version 1.0.0 is now released!

Along with various improvements, bug fixes, and more test cases, the key change is the introduction of a new Renderer trait. This allows other developers to create simple code renderers without handling the full generation process. It uses data from a pre-generated structure, making custom renderer development much easier.

As always, I’d love to hear your feedback! :slightly_smiling_face:

8

Hey guys,

I release a new version of xsd-parser :slight_smile:

This version introduces boxed quick_xml deserializers, significantly reducing stack usage during deserialization and improving stability for deeply nested XML structures. The naming of generated types has also been improved to ensure better readability and consistency across generated code.

Another major enhancement in this release is the ability to split the generated code into multiple module files, making it easier to manage large schemas. It also expands our documentation with advanced examples that demonstrate how to leverage the new features in real-world scenarios.

This release also includes various general bug fixes and improvements to ensure a smoother experience.

Give it a try and let me know what you think :slight_smile:

9

Hey guys :slight_smile:

I just released v1.2.0 of the crate, and it comes with some nice improvements under the hood and a bunch of new features and fixes. Here’s what’s new:

  • Refactored pipeline: There’s now a proper Renderer step and a DataType model. This makes things more modular and easier to extend.
  • Better serde integration: Serde support is now split into dedicated renderer steps. That means cleaner support for different versions like serde-xml-rs 0.7 and 0.8.
  • Support for unstructured XML: You can now work with xs:any and xs:anyAttribute - great for handling flexible or unknown schemas.
  • BigInt/BigUint support: Schemas with unbounded integers now map to num types.
  • Docs in generated code: XSD xs:documentation is now included as Rust doc comments.
  • Fixes and tweaks:
    • Enum restrictions and complex types render more accurately
    • Nested elements now get prefixed to avoid name clashes
    • Per-type derive settings
    • Tons of cleanup in naming, formatting, and escaping

Give it a try and feel free to share feedback or ideas!

1 Like