Thanks Stephen. Yes, given time, I'd like to pursue developing an automated solution to provide the FOR EACH type processing for creation of child Elements and Attributes within templates. (May be getting in over my head, but should be an interesting exercise.)
I might not be following what you want 100% but it sounds to me like you are trying to denormalise your structure into the single substation Element Template.
Regardless, there may be a workaround in AF 2.7 onwards that doesn't need code...
If your Feeder template was updated to include a "Name" attribute which was using the StringBuilder with a config of %Element% then you could do something like the following:
- Create a "Feeders" Attribute in your Substation and below that add a number of child AF Attributes (the maximum you would typically expect for a substation).
- Each one of those child Attributes is named with an index number, e.g. Feeder1, using the StringBuilder again but with the config '.\Elements[@Template=FeederTemplate]|Name' where the index number  is replaced with  etc for however many Feeders you pre-create.
- Create instances of the Element Template, then run a one-time activity (could be a script) to "Hide" those AF Attributes that don't resolve (hide = check the Excluded property when instantiated).
- You would need to repeat the process for each piece of data you want lifting from a feeder to the Substation.
Apart from that you would have to use some code. I've wondered about having a Dynamic Data Reference that will check if its host Element is "dirty", if so then run some code to dynamically add/remove AF Attributes below based on its config (similar to what you describe). With this approach your Element Template will hold the rules but when being created the Data Reference executes the rules.
Thanks Rhys. I think you (and Stephen and Roger) have confirmed my suspicions as to what I can and cannot do, vis-a-vis, unknown quantities of child elements and attributes for templates.
My intent is to 'black box' the process of creating new Substation Elements; to simplify creation of new Substation Elements by AF Admins as much as practical. Especially when there are a significant number of substations to add, each of which would have large and varying numbers of Feeders.
When time allows, I may pursue creating an app that would do this (as Stephen mentioned). Of course, Roger's thoughts on using Excel/AF Builder to manipulate the structure may be suitable for 'packaging' into a list of tasks when the PI AF Admin needs to add new substation Elements.
I think the best solution mainly depends on the process to create and maintain your asset model. In most cases, power users are able enough to build some logic in Excel to create the desired AF structure. Using the AFbuilder the AFModel is then created and/or updated quite easily.
The advantage of this is that power users can create and maintain the AFmodel with some limited knowledge of PI AF and PI Builder. Typically no programming (read: AFSDK) required.
To date i have not found a way to use the PI Point Arrays (open to suggestions though)
Hope this helps!
Thanks Roger. Though I'd like a more automated method, use of AF Builder may be a more easily and quickly delivered solution to what I'm trying to accomplish.