Ongoing work on generated validators?

[phdavis1027]

I am interested in this feature and quite willing to work on it, however in the interests of not duplicating work I wanted to check if there is existing code towards this. If not, what might a good starting point? any gotchas that others have already thought of?

[Bergmann89]

Hey @phdavis1027,

unfortunately, I haven’t had time to continue working on this, as I’m only doing this project in my spare time. I know that @rcbevans was also interested in this topic (see #18).

The plan is roughly as follows:

• Add parsing of Schematron files to the parser:

  • Use the XSD schema for Schematron files to generate code for parsing (this is already done in the schematron branch)
  • Add methods to the parser to load Schematron files using the generated code
  • Find a suitable crate for parsing XPath expressions (originally I planned to implement this myself, but using xee-xpath seems like the better option)

• Extend the interpreter to understand Schematron:

  • Implement a suitable data type to store Schematron information alongside (or within) the existing MetaTypes
  • Extend the interpreter pipeline to process and validate the raw Schematron data and convert it into a form that is easier to handle in xsd-parser

• Changes to the generator pipeline are still unclear; we’ll determine what’s needed during implementation of the render step

• Implement a new render step to generate validator types:

  • Similar to the serializer and deserializer, this step should generate types that can validate a stream of quick_xml events
  • This allows validation before deserialization (input validation) or after serialization (output validation)
  • The validator should check the general XML structure (some logic may be reusable from the deserializer)
  • It should also apply the rules defined in the Schematron file
  • An advantage over the current deserializer is that the validator doesn’t need to return data, so it can use dynamic types (e.g. Box<dyn Validator>) instead of generics (e.g. Deserializer<T>). This enables using a real stack (Vec<Box<dyn Validator>>) instead of the call stack, which should simplify handling, improve performance, and reduce memory/stack usage
  • If this approach performs significantly better (which I expect), I’d consider updating the serializer and deserializer to use a similar stack-based, dynamically dispatched approach, but this is out of scope for the validator topic
  • Optionally, we could implement fully dynamic validators that use data from MetaTypes instead of generated types. This would reduce code size or the need to generate code but increase memory usage and always require processing the entire schema file

If you’re willing to drive this topic, I’d suggest the following workflow:

• Create a dedicated feature branch
• I’ll give you write access to the repository so you can work directly here (avoids syncing between forks and makes it easier for me to contribute as well)
• Implement each major step as a separate PR (to simplify reviews)
• Merge approved PRs into the feature branch
• Once Schematron support and the validator feature are complete, merge the feature branch into master
• Finally, create a new major release (likely v1.6.0)

What do you think?

Best,
Bergmann 🙂