Relying on strings and doing a straight substitution of placeholders is not a very practical approach, especially with the need to support user-provided (Users that implement providers) specifications for resources.
A better approach will be to expand placeholders as their own structs with the reference information. Similar to HTML DOM nodes, string fields should become a slice of nodes that can be either text nodes or substitution nodes.
For core blueprint specification components, string values that support substitution must be replaced with a slice of nodes.
This means custom resource specs can't be completely at the discretion of the user with their own types, we need to ensure that all strings are slices (lists) of nodes.
In order to do this we need to create a tree structure for resource specs.
Relying on strings and doing a straight substitution of placeholders is not a very practical approach, especially with the need to support user-provided (Users that implement providers) specifications for resources.
A better approach will be to expand placeholders as their own structs with the reference information. Similar to HTML DOM nodes, string fields should become a slice of nodes that can be either text nodes or substitution nodes.
For core blueprint specification components, string values that support substitution must be replaced with a slice of nodes.
This means custom resource specs can't be completely at the discretion of the user with their own types, we need to ensure that all strings are slices (lists) of nodes. In order to do this we need to create a tree structure for resource specs.