Gazebo | Ignition | Community
Ask Your Question
0

Improve front-end. Why using XML?

asked 2020-04-17 19:25:50 -0600

jmoxoby gravatar image

This is a design question. I'm trying to understand the logic behind some decisions.

Why are we using XML as the front-end to specify world/models? It seems to me that using, for example, a python script to build the graph structure of a model is way easier than struggling with an XML file. This python script can return a data structure that can be loaded directly into a C++ one through bindings.

XML is painful. Why are we doing this to ourselves?

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
0

answered 2020-12-18 14:36:16 -0600

chapulina gravatar image

Thank you for the question. This is something we briefly considered changing when refactoring things from Gazebo classic to Ignition Gazebo, and decided to stick with the existing XML-based SDFormat to reduce the number of moving pieces.

More generally, I think "the XML question" can be split into 2 broader questions:

  1. changing to a different markup / declarative format like json or yaml
  2. changing to a programming language like python

Your question is related to number 2, so I'm not going to address number 1 now.


While a programmatic way of describing a world could allow users more flexibility, a declarative approach is usually easier to debug and maintain.

One parallel example that's interesting to think about are ROS 2 launch files. ROS 1 used XML, but users wanted more flexibility, so the initial implementation on ROS 2 was python-based. And interestingly, that introduced so much friction that an XML interface was added shortly after. I think their rationale for XML support fits our situation as well:

As an alternative to a programmatic approach to the ROS 2 launch system’s API, a declarative description features a WYSIWYG approach, easier to read, audit and maintain. This is the preferred approach for ROS 1 roslaunch launch files, thus some degree of familiarity is expected (and relied upon).

In any case, I think it would be valuable to eventually support a programmatic way of describing SDF worlds. We currently have a C++ interface to the SDF DOM, so that could be wrapped for a scripting language like python.

As an intermediate solution, we've also been extensively using ERB to template SDF files, which maintains some of the declarative approach while also bringing the power of a fully-fledged programming language (ruby).

edit flag offensive delete link more
Login/Signup to Answer

Question Tools

1 follower

Stats

Asked: 2020-04-17 19:25:50 -0600

Seen: 30 times

Last updated: Dec 18 '20