There have been a few users decrying the recent change that forbids duplicate names for structure elements. So I figured I should take the time to explain that this change was not taken lightly. We always strive to make Realm Works as flexible as possible, and as adaptive as possible to every user's preferences. It's extremely rare that we remove some aspect of flexibility from the product, but this happened to be a very special case.
The problem centers on the export and re-import of material. The presence of duplicate names introduces some profound complications into that process when combined with a variety of situations that can arise. In the normal case, duplicate names are no issue whatsoever. However, in these various situations we've identified, the reliability of the export and import is compromised when duplicate names are introduced into the structure. These are NOT obscure cases, either. They happen to be cases that users ran into and then reported to us as problems (typically as crashes during import that we investigated and tied back to the naming issue).
We've been working to come up with a solution to these use cases for the past few weeks. Unfortunately, everything we came up with still had a hole when duplicate names were involved. In the end, we determined that the only way to ensure that export and import could be made 100% reliable was to preclude the use of duplicate names. The export and import mechanisms are fundamental to the imminent Content Market, and content sharing in general, so duplicate names became something that could no longer be supported.
Thankfully, the percentage of users impacted by this new restriction is extremely low, as the vast majority of users don't have any duplicate names whatsoever across their realms. However, that doesn't help those of you who actively leverage duplicate names for specific purposes. To those of you in this select group, I'm genuinely sorry that we had to impose this restriction. There simply wasn't another way forward that allowed us to fully support both export/import and duplicate names.
There are a few potential workarounds that can be used to get around this new limitation that I can share...
Snippet types with the same name are where this limitation will most likely impact users. Since it is simple to create a snippet based on a type in one section and then move it to another section, the names must be unique across an entire category - not just within a given section definition. However, this very behavior presents one workaround option. Instead of having a snippet type with the same name in multiple sections, you can define it in only one. Then you can create a snippet based on that type in whatever section you need it. The key drawback of this approach is if you want to auto-add snippets for each of these types in multiple sections, which this approach doesn't support.
Ideally, two snippets types with the same name in different sections can ultimately be named distinctly. Since they appear in different sections, are they truly the EXACT same thing? Or are there subtle differences based on the section? If there are even minor differences, then perhaps one of them can be renamed without negatively impacting way derived topics/articles are presented. However, if they ARE the same thing, this isn't a viable option.
If you truly need the "same" snippet type in multiple sections, then the simplest solution is probably to just name them slightly differently. Even a single character of difference is sufficient (although changing letter case is not). Obviously, this isn't an ideal solution, since you end up with minor differences in the name/label based on where the snippet occurs in the topic/article, but it does enable you to have "near" duplicates. For example, if the name is two words, you could insert an extra space into one of them, resulting in only a very subtle difference in the label shown that doesn't really impact the readability of derived topics/articles.
Category names are only really used during creation of a new topic/article, and having two categories with the same name, even in different family groupings, is probably going to be confusing sometimes. Consequently, when categories have duplicate names, it's usually not that big of a deal to just rename one to something distinct.
Tag domains and section definitions are conspicuously absent from the list above. Tag domains and section definitions with the same name are typically going to cause all sorts of confusion. I can't think of where this would be a good strategy, so I'm not sure what a good workaround would be. If someone has an example where they leveraged duplicate names for either of these structure elements, please let me know the scenario and I'll do my best to recommend a workaround.
I realize that none of these solutions is ideal. Imposing this naming limitation in the first place isn't ideal. Unfortunately, it's a necessity. So I'm just trying to come up with ways to help those of you who are impacted work through this change and get something that comes close to what you had before.
Hope this helps!
The problem centers on the export and re-import of material. The presence of duplicate names introduces some profound complications into that process when combined with a variety of situations that can arise. In the normal case, duplicate names are no issue whatsoever. However, in these various situations we've identified, the reliability of the export and import is compromised when duplicate names are introduced into the structure. These are NOT obscure cases, either. They happen to be cases that users ran into and then reported to us as problems (typically as crashes during import that we investigated and tied back to the naming issue).
We've been working to come up with a solution to these use cases for the past few weeks. Unfortunately, everything we came up with still had a hole when duplicate names were involved. In the end, we determined that the only way to ensure that export and import could be made 100% reliable was to preclude the use of duplicate names. The export and import mechanisms are fundamental to the imminent Content Market, and content sharing in general, so duplicate names became something that could no longer be supported.
Thankfully, the percentage of users impacted by this new restriction is extremely low, as the vast majority of users don't have any duplicate names whatsoever across their realms. However, that doesn't help those of you who actively leverage duplicate names for specific purposes. To those of you in this select group, I'm genuinely sorry that we had to impose this restriction. There simply wasn't another way forward that allowed us to fully support both export/import and duplicate names.
There are a few potential workarounds that can be used to get around this new limitation that I can share...
Snippet types with the same name are where this limitation will most likely impact users. Since it is simple to create a snippet based on a type in one section and then move it to another section, the names must be unique across an entire category - not just within a given section definition. However, this very behavior presents one workaround option. Instead of having a snippet type with the same name in multiple sections, you can define it in only one. Then you can create a snippet based on that type in whatever section you need it. The key drawback of this approach is if you want to auto-add snippets for each of these types in multiple sections, which this approach doesn't support.
Ideally, two snippets types with the same name in different sections can ultimately be named distinctly. Since they appear in different sections, are they truly the EXACT same thing? Or are there subtle differences based on the section? If there are even minor differences, then perhaps one of them can be renamed without negatively impacting way derived topics/articles are presented. However, if they ARE the same thing, this isn't a viable option.
If you truly need the "same" snippet type in multiple sections, then the simplest solution is probably to just name them slightly differently. Even a single character of difference is sufficient (although changing letter case is not). Obviously, this isn't an ideal solution, since you end up with minor differences in the name/label based on where the snippet occurs in the topic/article, but it does enable you to have "near" duplicates. For example, if the name is two words, you could insert an extra space into one of them, resulting in only a very subtle difference in the label shown that doesn't really impact the readability of derived topics/articles.
Category names are only really used during creation of a new topic/article, and having two categories with the same name, even in different family groupings, is probably going to be confusing sometimes. Consequently, when categories have duplicate names, it's usually not that big of a deal to just rename one to something distinct.
Tag domains and section definitions are conspicuously absent from the list above. Tag domains and section definitions with the same name are typically going to cause all sorts of confusion. I can't think of where this would be a good strategy, so I'm not sure what a good workaround would be. If someone has an example where they leveraged duplicate names for either of these structure elements, please let me know the scenario and I'll do my best to recommend a workaround.
I realize that none of these solutions is ideal. Imposing this naming limitation in the first place isn't ideal. Unfortunately, it's a necessity. So I'm just trying to come up with ways to help those of you who are impacted work through this change and get something that comes close to what you had before.
Hope this helps!
If that were the issue, we could have focused on teasing that apart, which would have been a non-trivial amount of work but still tractable.