jwnimmer-tri
commented
2 years ago As background: Non-schema XML elements are already reported to the user, e.g., if they type <jiont> instead of <joint> they already receive a message today.
The main focus here is known-but-unsupported modeling elements, e.g., <light> or <placement_frame> etc.
The brute force way to implement what we need would be to take the SDFormat C++ DOM that is produced by the libsdformat parser, and inspect it to acutely check for unsupported modeling elements.
For example, we could warn anytime the sdf::World::ActorCount() > 0:
https://github.com/ignitionrobotics/sdformat/blob/0fa9e786507c2ac72c41a987e85dd2a02110b92e/include/sdf/World.hh#L250
That will be a lot of C++ calls, but at least will be easy.
That will cover the sdf-namespaced elements. We also need to handle drake-namespaced elements.
When libsdformat finds an XML element with a custom namespace (e.g., <drake:foo>), it copies it into a sidecar of the C++ DOM, that we need to go poke ourselves, e.g.
When there is a drake: element that we don't recognize, that should be an error.
Another way do to it would be to operate on the type-erased element tree DOM. There is an element tree created during the parse, prior to mapping the element tree into the C++ DOM. We could walk that programmatically and check that every element or attribute matches an allow-list of known-parsed names.
That would probably be less code, but would split out list of "supported elements" into different places in the code. With testing though, I think the risk is probably low.
For severity (error vs warn), I think we want the following:
Elements outside of the schema are error. SDFormat already handles this for sdf-namespace elements. We need to do it ourselves for drake-namespace elements.
Elements that are defined but not supported are warnings. We need to do this for sdf-namespaced elements. By definition, there are no drake-namespace elements of this class.
Unknown namespaces (e.g., <myrobotcorp:specialjoint>) are warnings.
Split from #16229. The SDFormat parser should issue an explicit warning for documented SDFormat tags that it ignores. Best implemented after #16784 is complete.
Victory condition: given a list of SDFormat tags for whatever version we claim to support, demonstrate that the SDFormat parser either implements the tag by constructing relevant plant features, or warns that the tag is being ignored.