I’ve here suggested introducing an ACTIVE/INACTIVE TAG to OSC Query.
This tag can PERHAPS also be used for picking between parallel ways to access the same model information, e.g. colour, besides the use of enabling disabling methods that vary depending on sub-class. But I’m unsure.
Actually, OSC Query provides an Optional TAG which covers part of this already, of allowing alternative type-tag-strings. Just that not all OSC Query servers support it…
I’m not yet sure if duplicating functionality in a namespace is fully avoidable.
Splitting R G B allows using any OSC capable application/device, even those which do not support composite type-tags (e.g. fff), which unfortunately is not uncommon. Colour I guess can always be set with R G B, and it is up to the GUI creator to allow alternative HSV etc options, and translate internally.
But the need arises for more up-to-date/fully featured applications to employ a flag such as this to pick between alternatives.
It is important to stress, that the INACTIVE tag is about the state of the value in the Server MODEL. The OSC client GUI can and should have separate features for choosing to display or not display a sub-section of the Namespace tree.
Thinking about it more, Specifically using the ACTIVE tag to pick between groups, would mean they also need a GROUP ID, or the OSC Client cannot know which of the many that is picked! So, RGB is id 0, R, G, B, are each ID 1, HSV id 2, H, S, V are 3, etc…? That, and that all are also on the same level, children to the same OSC Container…
I am, to conclude for now, not certain what the best way forward is on this problem – yet!