sdf_tutorials

sdf_tutorials copied to clipboard

The SDFormat 1.7 frame semantics proposal contains two restrictions on the contents of //@name attributes:

• Names of sibling elements must be unique
• Certain reserved values may not be used in a //@name (namely world and __.*__

Should these restrictions apply to a name attribute in a custom namespaced element?

Moved from this comment thread: https://github.com/osrf/sdformat/pull/381#pullrequestreview-518802131

I think it makes sense to relax these requirements when it comes to custom elements.

Agreed. I dunno if I can come up with a real use case where you want @name to be non-unique, but ideally we do as little as possible when it comes to custom elements / attributes.

Agreed. I dunno if I can come up with a real use case where you want @name to be non-unique, but ideally we do as little as possible when it comes to custom elements / attributes.

what about //drake:joint from https://github.com/RobotLocomotion/drake/pull/13824 ?

I don't think that's an issue?

After reviewing: https://github.com/osrf/sdformat/issues/288

1. If it stays as //drake:joint, then it's Drake's responsibility to inject frames / test for conflicts, so libsdformat should have no duty there.
2. If it does get implemented using //joint/@type="custom", then it's already handled.

If (1) happens, then yeah, we have to inject frames via some hook API (yuck), so I think it'd still fail fast in the right way, just with dumb error messages.

I don't think that's an issue?

After reviewing: osrf/sdformat#288

1. If it stays as //drake:joint, then it's Drake's responsibility to inject frames / test for conflicts, so libsdformat should have no duty there.
2. If it does get implemented using //joint/@type="custom", then it's already handled.

If (1) happens, then yeah, we have to inject frames via some hook API (yuck), so I think it'd still fail fast in the right way, just with dumb error messages.

I would like to see //joint/@type="custom" supported rather than encourage people to make custom joint elements for this reason, but i suppose it makes sense to still err on the side of not interfering with custom elements

Agreed on that point! (//joint/@type="custom" smells wayyyyy better than the other alt.s)