How to avoid/prevent name collisions on labels and other attributes, when they're defined and used by add-ins

[InjAnnuity1]

Context: I plan to evaluate Trilium (and plug-ins) for potential developer/business use. I've used CherryTree, TreeLine, TreePad, NoteCase Pro, ToDoList, MyInfo, and others, but none was quite the right fit. TreeLine came closest, data-wise, with the ability to define strongly-typed notes, with named, strongly-typed datums, but it dropped its ability to add plugins years ago.

Trilium looks like it can do the same job, and much, much more.

Suppose I was going to create my own add-in, with its own set of note attributes. How would I keep my add-in's note-attribute names from colliding with Trilium's (present and future), or from other add-ins' names? Is there a naming convention in place to prevent such collisions? If not, can we hash one out, here?

[sottey]

As in coding, namespaces are the obvious choice.

Simply prepend a unique string to the descriptive attributes.

Example

#sottey.tje.datanote

The odds on someone else using that unintentionally are tiny.

Am I missing a requirement here?

[InjAnnuity1]

Not at all. The namespace concept is exactly what I'm looking for. Yours is the first Trilium example I've seen, however, even suggesting that such a thing is even possible in Trilium.

Looking in the Wiki, I failed to find any specification of legal attribute syntax. Looking in the titles on this discussion forum, I failed to find any discussion of legal attribute syntax, nor conventions that the community has come to agree upon. So I've relied on the examples provided in the Wiki. And all the examples I remember are single, JavaScript-style identifiers.

This makes it harder for me to understand what I need to do to "play nice", and work with the machinery and within the conventions that already exist. It makes me wonder what barriers or tradeoffs are in place, in the app, add-ins, or api, that's prevented the use of hierarchical names (namespaces).

Suppose, for example, that I settle on a prefix, and discover later that someone else is already using it. Or that the agreed-upon convention uses (say) slashes instead of periods. I could probably just do a global search-and-replace on my own naming system, to keep compatibility. But I find it best to ask about these things up front, to avoid getting into those situations in the first place.

And asking in public means that the answers are also public, and can help others when they stumble across the same questions.

[sottey]

While the possibility of someone using a very specific string is non-zero, it is very small.

Naming collisions shouldn't be a serious concern is you use something highly unique.

As for best practices, if you see most existing attributes are using a standard (camel case, dotted namespaces, hyphen delimiter. Etc. ) then you can use it.

[InjAnnuity1]

No worries. I can reverse-engineer a concrete specification, evaluate the practical tradeoffs of different syntaxes and separators. Just not immediately. When I have it worked out, and posted here, then the information can make its way into the documentation, so that others don't have to do that R&D all over again.

[rauenzi]

There is no concrete specification of any kind for attributes used by addons, so collisions are technically possible. This is something that would be interesting to tackle with a more "proper" plugin system, but as of right now it's more like a free-for-all. There is a list in Trilium of current attributes that you should avoid colliding with, but there is no way to prevent future collisions. That said, as @sottey mentioned, if you use a prefix or suffix of some kind for your attributes then it's highly unlikely you would collide with anything. For example many of my addons use a simple word based prefix. Like for my markdown preview addon, all the important attributes start with markdown such as #markdownScrollSync