I do not think you need to import the substituting template: the whole point is that it should be left to the orchestrator to "stitch" things together.
However, I do think you at least need the substituted node type to be known, so that the parser can validate the mappings. So it might make sense to have a "types.yaml" or similar that you import both at the server and client templates. ARIA's validation errors in this case would be 1) if it doesn't recognize the node type name, 2) if the mappings don't refer to declared reqs-and-caps, and 3) if the substituted reqs-and-caps don't match in types. (Note that you are allowed to substitute a child type, because the polymorphic contract is still in place.) Maybe point us exactly to the section in the spec that is confusing here and we can try to understand it together. On Thu, Aug 10, 2017 at 1:35 PM, Steve Baillargeon < steve.baillarg...@ericsson.com> wrote: > Quick questions about YAML 1.0 and substitution mappings > In section 2.10.2 where it shows the definition of the top-level service > template. > The example does not show the import definitions. > Can you confirm the top-level service template must import the > substituting service template(s)? > Will ARIA currently generate a validation error if the import definition > is missing in such case? > Will ARIA currently generate a validation error if a valid import > definition is provided but does not contain the definitions for the > abstract node? > The text refers to a "substitutable directive" in the top-level service > template. Is Datapoint_enpoint=db the "substitutable directive"? > Regards > Steve B >
