Is 'name' property on elements intended to be unique?

[sean-maptek]

There is no validation rule to checks that each element in a project has a unique name.
The absence of such a check doesn't eliminate the possibility that it was intended to be unique.

The description of the name property in the documentation simply says "Title of the object" and doesn't clarify if its suppose to be unique or not.

If its not intended to be unique, there is no clarification on what software vendors should do about this situation.
Not every software package may be able to use the UUID to meet a uniqueness requirement and it would also be rather odd if the user imported multiple point set elements called "collar" as they would then be faced with four "collar" objects listed in their explorer. Should the recommended approach to be like Windows Explorer and name subsequent ones of the form "name (number)"?

The two questions here are:

• Is 'name' property on elements intended to be unique?
• If the answer is no, then what is the recommended way to handling it?

[fwkoch]

From my perspective, OMF should not enforce unique name values. I think this is potentially too constraining. Using your example, maybe I do just want to have a single OMF file to interchange "collars" for multiple projects - a strange use case, no doubt, but I don't think the format should get in the way. There are other ways to make the objects non-unique, e.g. description or other metadata or maybe even just different underlying binary is enough.

Then I think it comes down to the client consuming OMF files. If the client cares about unique names, it can take your approach with "name (number)" when displaying the objects. Alternatively, it could have some sort of importer that displays the metadata and lets the user decide how to proceed. Or... it could just ignore all but the first the duplicate named item (and document this behaviour).

It's definitely worth documenting some best practices, but I'm not even sure where these sit, e.g. (1) best practice is to keep names unique in an OMF file or (2) best practice is to assume nothing about names when consuming an OMF file and rely on other metadata if you are trying to key off a unique value. My preference is (2) - that lends itself to the most flexibility - but (1) is certainly viable as well.

[sean-maptek]

Using your example, maybe I do just want to have a single OMF file to interchange "collars" for multiple projects - a strange use case

It's not so much a strange use case as a consequence of the relaxed requirements of the OMF format and as such the program writing the OMF being simple. If the software package has the the concept of folders, then that can remove the ambiguity in the software package. However, when it comes to export from the software package to OMF then it is a case of (1) the writer needs to combine the name of the folder and the name of the object to help make it unique and easier to track in the resulting OMF project.

Best practices

• (1) puts the onus on the OMF writer
• (2) puts the onus on the OMF reader

Flexibility also comes with complexity, not only to the implementers but also to the end user, as ambiguities that can't be resolved systematically via software need to be moved up to requiring user input.

I agree, documenting best practices would be a good approach.