If you implement
capability "Variable", your attribute would have to be named
variable--that's the one specified by this capability. Further, you'd need a
setVariable() command, which is the means by which the
variable attribute is set. I can only assume this was created to handle Rule Machine global variable device connectors. Outside of that, it probably has little real-world use, and this itself was probably only there so apps could have a way to select these devices when the connector was created using this more generic capability instead of a specific "standard" capability (like switch or dimmer).
This is probably going to become even more obscure as more apps move towards the use of the new-ish hub variables feature and the ability to read, set, and subscribe to them directly without the need for a full-blown device (a gap that connectors--of any type--filled).
So, if you want a custom attribute named
dewPoint or whatnot, I'd suggest continuing to do that, by all means. The above wouldn't really make sense to me, especially as the capability also requires a command to set this value, whereas dew point is really just a calculated value--read-only, from the user's perspective. (If you want to stick to standard attributes only, i.e., those from capabilities, but you are already using
temperature for something else--likely actual temperature, as I assume your driver would--then you could consider creating a child "dew point" device with the temperature measurement capability and exposing the dew point via that. This is a standard attribute, so perhaps usable in more apps more easily. But some people don't like the clutter child devices arguably help create, and if you're already happy with how you're able to use the custom attribute, then...no need.)