Provide the ability to have attribute template that can be used in multiple element templates (attribute sets)

The example that you gave is not the best, since you could have a "Motor" base template and create 3 derived templates. Here's a better example. Where I work, almost every equipment has an equipment number (EN). Naturally, I made an "Equipment With EN" template. Almost every equipment with an EN also has a run status (on/off) (RS). Naturally, I made a derived template "Equipment With EN And RS". However, some equipment that do not have an EN also have a RS, and some equipment have an EN but not a RS. So do I make another template called "Equipment Without EN But With RS"?: Equipment With EN ↳Equipment With EN And RS Equipment Without EN But With RS Or should I have made my hierarchy like this instead?: Equipment With RS ↳Equipment With EN And RS Equipment Without RS But With EN Or should ditch the benefits of inheritance to treat EN and RS equally?: Equipment With EN Equipment With RS Equipment With EN and RS You can find a similar example in the programming world here: http://ece.eng.umanitoba.ca/undergraduate/ECE3740/Lecture%20Slides/L36PlayerRoleDesignPattern.pdf Templates for attributes (not to be confused with attribute templates) would solve this problem, since any number of these templates can be used on any number of element templates. Single-parent inheritance only lets us have 1 template for attributes. For my example above, I would make 2 templates for attributes: EN and RS, and I would associate EN with "Equipment With EN" and "Equipment With EN and RS", and I would associate RS with "Equipment With RS" and "Equipment With EN and RS". Besides solving the multiple inheritance problem, templates for attributes would allow for consistent naming of the same type of attribute and would reduce repeated configuration across multiple element templates. Let's not forget about child attributes. Some child attributes besides the limit traits are repeated across many different parent attributes. For example, where I work, attributes that are regulated by PID controllers regularly have the following child attributes: Hi, Lo, Setpoint, Output, Mode, Rate, Reset, Gain. It would be useful to make a template for, say, Output, that can only be used as a child attribute. OSIsoft needs to think carefully about when hierarchies (one-to-many relationships) are appropriate and when graphs (the graph theory kind of graph) (many-to-many relationships) are appropriate. Keep in mind that hierarchies are a type of graph, so hierarchies are more restrictive.

I would like to add my thoughts. This would provide the same functionality as what I have been thinking I need. What I was thinking is that I would like to have an element template with multiple base templates. one use case is similar to Kenneth's, where we would like an equipment template for motors, high voltage or low voltage and variable speed or fixed speed. So at the moment, if we have all four combinations, we need to choose the template hierarchy as either voltage>>speed control type or speed control type>>voltage. And then whatever we pick as the lowest in the template hierarchy, we have to maintain the set of attributes in multiple places. A similar situation arises where we have a KPI rollup hierarchy. We want the same type of hierarchy over multiple sites. Each site may require different attributes for data input or calculation, so require a derived template applicable to the site. We also need to maintain different templates depending their place in the hierarchy. This gets very messy to maintain if you have, say, 3 functional layers, then need to maintain site-specific attributes. What I would love is to have, for instance, 4 templates. tpt1 tpt2 tpt3 tpt4 where tpt1 tpt2, tpt3 have no base template. But then tpt4 can have base template= tpt1 AND another option called 'include'=tpt2;tpt3. Any commonly name attributes could be overriden on the order listed, so tpt3 definition would override tpt2 and tpt1. tpt2 would override tpt1. As we move forward trying to standardise solutions across multiple sites, having this flexibility would prove invaluable.