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

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

Reply via email to