Hej!
I know it works, technically, but is it a good idea?
Short answer: no. It's a Bad Idea
TM.
Will storing UUID in the Keywords attribute for some elements come back to bite me down the road, because I won’t be able to use some Sparx feature I’m not even aware of yet?
In the case of Keywords I'm not aware of any built-in features which use it as of now. But that might change.
Sparx Systems do not publish any roadmaps and don't let anyone know what's in the pipeline, so a currently unused built-in property may well get worked into some new feature at some point.
A couple of releases ago, if someone had asked whether the Version property could be used to store custom data, the answer (according to the same reasoning) would have been Sure, go ahead -- but since then, new functionality has come in that actually uses the Version property. Which you don't have to use, but it puts you in the position of having to choose.
So it's a hard no. Use a tagged value instead, that is precisely what those are for: to extend the built-in metamodel with your own stuff.
If you want to keep it light, you don't have to design a profile or even define a tagged value type. You can just add tagged values on the fly in your script.
I do recommend that you define it all properly, but you don't actually have to.
Out of curiosity, have you looked at the
DataMiner API? Or writing a
cloud server custom plugin?
Both are new, both undoubtedly have useability issues, but they are both intended to address tool-to-tool integration.
/Uffe