Chris Lauwers

Yes, my parser implements the same behavior: it checks if the type of the value referenced by 'get_property' or 'get_attribute' calls matches the type of the parameter definition that uses...

Now that we can specify valid source node types and valid target node types, we should theoretically be able to validate any properties or attributes referenced using the SOURCE and...

The Ubicity orchestrator incorrectly flagged the “type” keyword in the output definition as an error. We have fixed this in the latest version. You are correct that the spec needs...

Ubicity checks whether the return types of a function is compatible with the type of the property for which it is defined as the value. It handles nested functions, and...

I’m not suggesting we should standardize this. However, when we revisit the discussion about custom functions, we should discuss whether these custom functions should define their return type (my vote...

I agree with Peter. "Dangling requirements" are specific to service **templates** only. When the orchestrator creates a service representation based on the template, all dangling requirements must be fulfilled. The...

In my opinion, templates should only be used to create representations, not other templates. We already have proposals for creating multiple representations from the same template (using the ‘occurrences’ keyword...

My vote is for removing it.

Alternatively, we can suggest design patterns that avoid the issue. I try to use a level of indirection where I pass the name of a secret or a reference to...

When deciding whether a keyname is mandatory or not, we should only consider the initial definition case, not any refinements (since in refinements all keynames are non-mandatory). From: Tal Liron...