Should name attribute restrictions apply to custom elements?

[scpeters]

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: gazebosim/sdformat#381 (review)

[chapulina]

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

[EricCousineau-TRI]

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.

[scpeters]

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 RobotLocomotion/drake#13824 ?

[EricCousineau-TRI]

I don't think that's an issue?

After reviewing: gazebosim/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.

[scpeters]

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

[EricCousineau-TRI]

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