Publish XML schema for MJCF

[erez-tom]

MJCF is well-documented, but a formal schema is not available. A schema based on e.g. XSD, relaxNG, or schematron would help 3rd parties write their own validators. For example DeepMind's mjcf package required its own custom schema in order to properly verify and manipulate MJCF elements in Python.

[wookayin]

It'd be great to have the schema file published so users can benefit from completion and static validation. Dear maintainers, any plans for publishing xml schema?

[yuvaltassa]

@wookayin yes, we have such plans. We hope to complete this by the end of the year.

Do you have opinions about your preferred schema format? Options are:

1. XSD
2. relaxNG
3. relaxNG compact format
4. Schematron.

[kevinzakka]

I want to highlight the following MIT-licensed schema: https://github.com/ronansgd/xml-schema-mjcf

[graseln]

Hi, any update on the XML Schema for the MJCF for the MuJoCo 3?

[yuvaltassa]

No update unfortunately. Might happen in 2024. Thanks for showing interest.

[madhephaestus]

@saran-t Per your question in #1511 I do have a preference for xsd. I am writing, what I intend to be, a feature complete set of Java Bindings and have been using an existing (but out of date) set of XSD files to generate the marshaling classes and associated builders. I has worked very well! see: https://github.com/CommonWealthRobotics/mujoco-java/blob/main/src/test/java/mujoco/java/XMLtest.java

It might be worth considering adopting https://github.com/ronansgd/xml-schema-mjcf as a starting place. @ronansgd has made an excellent start to creating a full featured set of XSD files for the MuJoCo XML format.

I have put some time in updating the existing project adding the updates from 2.x to 3.x here: https://github.com/ronansgd/xml-schema-mjcf/pull/3/files

[saran-t]

@madhephaestus we're close to releasing a compiler API for use cases like yours that allows for incremental modification of the model without having to go through an XML.

Perhaps it would be a good idea to wait for that and see what's the best way to proceed?

[madhephaestus]

@saran-t I look forward to seeing that, sounds like a neat way of making dynamic systems! Would i be able to modify a body thats in the scene? Like switch a body from fixed to loose? Could I change the friction in joints simulating damage?

For my use case I need to keep all of the pointers of the actual APi hidden from the user. One bad access to a pointer and the whole jvm crashes. I need to wrap the APi for users in java safe types. This does mean coming up with a lot of the internal types after importing the API by hand. Using the XMlL and the marshaling code that is generated by the xsd files, i get builders with types that enforce the correct structure from the generated code. These types, since they just map to the xsd, are memory safe for the user at all times, so building the model is automatically generated and safe for the user out of the box. I do look forward to dynamic editing, but it would be less good for my specific use case.

[yuvaltassa]

Would i be able to modify a body thats in the scene? Like switch a body from fixed to loose? Could I change the friction in joints simulating damage?

Yes you can do all of that; anything you want really. If you want a preview, take a look at the (currently private) C API in user_api.h and the corresponding tests. Note that the parser has already been rewritten to use this. WIP, quite a bit of missing functionality.

Per your question in https://github.com/google-deepmind/mujoco/issues/1511 I do have a preference for xsd.

Can you articulate more precisely why you prefer XSD to RNG? (not counting "I had an XSD starting point and this is what I already have working" 🙂)

I have put some time in updating the existing project adding the updates from 2.x to 3.x here: https://github.com/ronansgd/xml-schema-mjcf/pull/3/files

One of the things I don't love about this is the spreading out across multiple files. Presumably this is not a hard requirement but a choice.

[madhephaestus]

There exists tooling (in fairness, that i am familiar with, so recomendations would be lovely!) to create the Java classes to marshal and unmarshal XML directly from the XSD descriptors. The tooling also generates memory safe builders for Java users. There is a also a nice intermediate byproduct of the XML that can be used for tweaking and sharing. I have spent a good part of my spring break using my Java code to generate an XML, and the simulate tool you provide to visualize and debug the generator.

My use case is procedurally generated, 3d printable robots that can be tested in simulation with user generated terrain and obstacles. See https://github.com/CommonWealthRobotics/BowlerStudio/#bowlerstudio . The hope is for as much of the MuJoCo API to be as readily accessible, and to do that the API and the marshaling code needs to come as automatically as i can make it from an upstream ground-truth. I only have the breaks in between teaching to work on this API and maintain it, so it is imperative for me that the workflow have as much automation as possible.

If you have some recommendation for a toolchain for generating marshaling, unmarshaling and builder Java code from RNG, I would be happy to take a look. In the meantime XSD -> JAXB -> jaxb2-rich-contract-plugin->[code-gen] is my tested and known path.

One of the things I don't love about this is the spreading out across multiple files. Presumably this is not a hard requirement but a choice.

Yeah, adopting just means that you have a working starting place. you could certainly make the official repo a monolith file. I would happily retool my auto-builders if there was an officially supported version.

---

EDIT: Ok, i admit this argument is basically "I had an XSD starting point and this is what I already have working", but in fairness, i really do not have any idea how i would make it work with RNG, and googling it just brings up random number generator code >.<