I think you just described actually converging on a shared schema?
“Hey we have a same named extension shall we agree how it works?”
This isn’t a problem to plan ahead for. And why there shouldn’t be an “extensions” coordination - this is what lexicons are for, including that com.example.myapp.badgesextradata can be added as extra data today.
No, I’m saying we can provide an extensions field that allows people to put their own extras on the badge that may or may not be intended to converge with other apps.
Having the extensions as an open union means that I can add data to the lexicon distinguished by my own NSID, so that I know it won’t conflict with anybody else’s definition of the same field.
My app can go ahead with something like:
{
"$type": "community.lexicon.badge.appearance",
"title": "Code Gitter",
"extensions": [
{
"$type": "app.superbadges.3dmodel",
"3dModel": "obj format 3d object",
"supportsAnimation": false
}
]
}
And I can do that without having to worry about other people’s 3dModel field having a different format than mine.
If I just add 3dModel and supportsAnimation fields to the lexicon, then it could conflict with same-named fields in either future versions of the lexicon, or in other apps which use the same name for their extension field.
Without official extensions that allow open unions, I have to try to make my field name extra unique like app_superbadges_3dModel.
And that is also less documented. With extensions I’m able to document my extension with a lexicon that is clearly surfaced in the $type NSID. If I just tack on extra fields to community.lexicon.badge.appearance there’s no indication of where to see the docs for my extension, and it’s officially unstable for an pp to depend on any fields I add.
So extensions gives us a way to allow for stable extensions to the lexicon that are also documented with lexicons.
I think there is value to allowing extension without having to create a whole new record for it, but maybe that isn’t a common sentiment.
I don’t like that the extra data records aren’t very discoverable when looking at the main record. You have to know that these other records that happen to have the same rkey are conventionally related to this record.
I don’t know, my mind could possibly change on that point, but it still feels pretty good, especially for something as “moddable” as badge displays, to have a designated extensions field.
I mean do what you like, but actively managing an “extensions” space is the whole reason that lexicons exists.
Stable extensions are by definition a lexicon by any other name, it’s just stuffed in an extensions object.
Additional data was an object that stuff got put into for events. Didn’t need managing.
It doesn’t and in fact shouldn’t be managed, and once you start talking about managing it, you should either put it in a shared lexicon directly (the one it is extending) or its own lexicon.
Anyway - my recommendation is to not go down this rabbit hole until you have this problem.