Hi Tal,
In the process of trying to clean up old emails, I came across your recommendation below, which I don t believe has been incorporated into the text. I have one question. You state:
If indirection is also to be supported---where the property is designated by an _expression_---then the above two sections could be rewritten as follows
I don t recall what you meant by if indirection is also to be supported . Would you mind clarifying?
Thanks,
Chris
From:
tosca@lists.oasis-open.org <
tosca@lists.oasis-open.org>
On Behalf Of Marton, Gabor (Nokia - HU/Budapest)
Sent: Thursday, May 20, 2021 3:11 AM
To: Tal Liron <
tliron@redhat.com>
Cc:
tosca@lists.oasis-open.org; Nemeth, Denes (Nokia - HU/Budapest) <
denes.nemeth@nokia.com>
Subject: RE: [tosca] Complex property composition
HI Tal,
I would like to comment on DÃnes first point, regarding the ambiguity of the property assignment definition in the specs. Maybe it could be handled in the specs in the following way (on top of the
TOSCA-v2.0 draft ):
4.4.8.2.1 Short notation:
[remaining the same]
4.4.8.2.2 Extended notation
The following multi-line grammar may be used in case of complex properties where separate assignments to individual member properties are needed:
<property_name>:
<property_name_1>: <property_value_1> { <property_value_expression_1> }
<property_name_2>: <property_value_2> { <property_value_expression_2> }
<property_name_3>:
<property_name_3_1>: <property_value_3_1> { <property_value_expression_3_1> }
...
...
property_name ,
property_name_1 ,
property_name_2 ,
... : represents the name of a property that will be used to select a property definition with the same name within on a TOSCA entity (e.g., Node Template, Relationship Template, etc.)
which is declared in its declared type (e.g., a Node Type, Node Template, Capability Type,
Data Type , etc.).
note that there is no limit to the depth of recursion indicated in the above example
property_value_1 ,
property_value_2 ,
... ,
property_value_expression_1 ,
property_value_expression_2 ,
... : represent the type-compatible value to assign to the property. Property values may be provided as the result from the evaluation of an _expression_ or a function.
If indirection is also to be supported---where the property is designated by an _expression_---then the above two sections could be rewritten as follows:
4.4.8.2.1 Short notation:
The following single-line grammar may be used when a simple value assignment is needed:
<property_name> { <property_name_expression> }: <property_value> { <property_value_expression> }
In the above grammar, the pseudo values that appear in angle brackets have the following meaning:
property_name ,
property_name_expression : represent the name of a property that will be used to select a property definition with the same name within on a TOSCA entity (e.g., Node Template, Relationship
Template, etc.) which is declared in its declared type (e.g., a Node Type, Node Template, Capability Type,
Data Type , etc.). Property names may be provided as the result from the evaluation of an _expression_ or a function.
property_value ,
property_value_expression : represent the type-compatible value to assign to the property. Property values may be provided as the result from the evaluation of an _expression_ or a function.
4.4.8.2.2 Extended notation
The following multi-line grammar may be used in case of complex properties where separate assignments to individual member properties are needed:
<property_name> { <property_name_expression> }:
<property_name_1> { <property_name_expression_1> }: <property_value_1> { <property_value_expression_1> }
<property_name_2> { <property_name_expression_2> }: <property_value_2> { <property_value_expression_2> }
<property_name_3> { <property_name_expression_3> }:
<property_name_3_1> { <property_name_expression_3_1> }: <property_value_3_1> { <property_value_expression_3_1> }
...
...
property_name ,
property_name_1 ,
property_name_2 ,
... : represents the name of a property that will be used to select a property definition with the same name within on a TOSCA entity (e.g., Node Template, Relationship Template, etc.)
which is declared in its declared type (e.g., a Node Type, Node Template, Capability Type,
Data Type , etc.). Property names may be provided as the result from the evaluation of an _expression_ or a function.
note that there is no limit to the depth of recursion indicated in the above example
property_value_1 ,
property_value_2 ,
... ,
property_value_expression_1 ,
property_value_expression_2 ,
... : represent the type-compatible value to assign to the property. Property values may be provided as the result from the evaluation of an _expression_ or a function.
4.4.8.3 Additional Requirements
[ ]
When p roperty names are
provided as the result from the evaluation of an _expression_ or a function , name collision (the name provided by the
_expression_ or a function colliding with the name provided by another
an _expression_ or a function , or a constant name, in the same map of keynames) shall be considered an error.
When p roperty names are
provided as the result from the evaluation of an _expression_ or a function , the _expression_ or function shall be evaluated at deployment time, i.e. the _expression_ or function shall not rely on runtime values (attributes) .
Greetings,
GÃbor
From:
tosca@lists.oasis-open.org <
tosca@lists.oasis-open.org >
On Behalf Of Tal Liron
Sent: Wednesday, April 21, 2021 9:13 PM
To: Nemeth, Denes (Nokia - HU/Budapest) <
denes.nemeth@nokia.com >
Cc:
tosca@lists.oasis-open.org Subject: Re: [tosca] Complex property composition
You are absolutely right about the ambiguity. Please see the discussion on this mailing list called "New syntax for function calls" that attempts to resolve this for TOSCA 2.0.
As for TOSCA 1.X, it was not specified but implied that a parser would prioritize detecting a function call first (a map with a single string key which is one of the recognized function names). But it was very much left
up to individual implementations to decide what to do. Would you get an error telling you that a function name is not known? Or would it be simply treated as a map value, leading to a data error if the data type is not a map?
(And there is also a rare edge case in which you actually have a data type property that is named the same as a TOSCA function, or you want to use such a name as a map key. TOSCA 1.X would simply not let you do this because
it would interpret that notation as a function call.)
Your point about nesting function calls as arguments to other functions is also on point. The TOSCA 1.X specs really did not clarify this. However, in examples we did see use of nesting. Again, I hope you can contribute
to the "New syntax for function calls" discussion, which goes into this in some detail.
To echo what Chris said, even when the spec is not entirely clear we can still have a good understanding of the "spirit" of what was intended. There are many such problems with the TOSCA 1.X spec. We are working hard to
resolve these ambiguities in TOSCA 2.0. Your feedback here is important. Whatever we do, we absolutely must clarify how nesting works in a deterministic way.
On Wed, Apr 21, 2021 at 1:40 PM Nemeth, Denes (Nokia - HU/Budapest) <
denes.nemeth@nokia.com > wrote:
Dear Tal
Are you sure about this, because the spec says that :
3.6.11.2 Grammar
Property assignments have the following grammar:
3.6.11.2.1 Short notation:
The following single-line grammar may be used when a simple value assignment is needed:
<property_name>: <property_value> { <property_value_expression> }
In the above grammars, the pseudo values that appear in angle brackets have the following meaning:
property_name: represents
the name of a property that would be used to select a property definition with the same name within on a TOSCA entity (e.g., Node Template, Relationship Template, etc.,) which is declared in its declared type (e.g., a Node Type, Node Template, Capability Type,
etc.).
property_value , property_value_expression: represent
the type-compatible value to assign to the named property. Property values may be provided as the result from the evaluation of an _expression_ or a function.
For me this definition would mean that the property can either have a fixed value assignment or can be specified via a Tosca function. It does not say anywhere that a property may
be constructed from multiple functions.
Would not the possibility of constructing a complex property look like this?
<propertyName>: <property_value>
{ <property_value_expression> } <composite>
<composite>:
<key>: <property_value> <composite>
, where <key> is a fixed value or
{ <property_value_expression> }
Maybe Puccini has more advanced capabilities that is described in the specs.
My second problem with this approach is that the parser can not the value of the property
p1:
child1:
get_input: simple_input_child1
value of the child1 is
get_input: simple_input_child (so a map that has one element with get_input key and simple_input_child value
xor
The value of the get_input function
In this case the parser is lucky because it can deduct that it is the 2nd Case (because of the type of child1 is string).
However in a generic case when such deduction is not possible and a complex property is constructed from N number of Tosca functions or fixed values.
The complex value may have 2^N variants (exponential), how should we choose which is the actual value.
Here is an example for the problem.
tosca_definitions_version: tosca_simple_yaml_1_2
data_types:
data_type_1:
derived_from: tosca.datatypes.Root
properties:
child1:
type: map
child2:
type: map
node_types:
node_type_1:
properties:
p1:
type: data_type_1
topology_template:
inputs:
simple_input_child1:
type: map
default:
a: b
simple_input_child2:
type: map
default:
c: d
node_templates:
node_template_2:
type: node_type_1
properties:
p1:
child1:
get_input: simple_input_child1
child2:
get_input: simple_input_child2
What is the resolved value of p1:
child1:
a: b
child2:
c: d
or
child1:
get_input: simple_input_child1
child2:
c: d
or
child1:
get_input: simple_input_child2
child2:
c: d
or
child1:
get_input: simple_input_child1
child2:
get_input: simple_input_child2
I think that at least some kind of precedence would be required between values and function. For example if the value of a property
can be evaluated as a Tosca function, than it is considered to be the value of the tosca function.
From:
tosca@lists.oasis-open.org <
tosca@lists.oasis-open.org > on behalf
of Tal Liron <
tliron@redhat.com >
Date: Wednesday, 2021. April 21. 18:26
To: Nemeth, Denes (Nokia - HU/Budapest) <
denes.nemeth@nokia.com >
Cc:
tosca@lists.oasis-open.org <
tosca@lists.oasis-open.org >
Subject: Re: [tosca] Complex property composition
Yes, I'm sure it is possible.
You can think of it this way: a data type just like a node template also has properties, so these both accept assigned values in the same way. This implies that you can
nest values to any depth.
The situation is less clear when we are dealing with list and map types. However, I think that it likewise should be possible. And for maps, it should even be possible
to use function calls for map keys. (Puccini supports all these cases.) Example:
node_types:
DataNode:
properties:
string_map:
type: map
entry_schema: string
topology_template:
node_templates:
data:
type: DataNode
properties:
string_map:
Greeting: Hello
Message: { concat: [ Good, ' ', Day ] }
{ concat: [ Recip, ient ] }: Puccini
On Wed, Apr 21, 2021 at 9:50 AM Nemeth, Denes (Nokia - HU/Budapest) <
denes.nemeth@nokia.com > wrote:
Dear Tosca community
Can you help us to clarify the usage of property assigment in node templates specified in
https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/os/TOSCA-Simple-Profile-YAML-v1.3-os.html#DEFN_ELEMENT_PROPERTY_VALUE_ASSIGNMENT Is is possible to assign parts of complex properties to node templates using property value expressions or not?
Node_template_1 assigns complex_input input to p1 property. There is several examples to this in the specs.
Node_template_2 constucts the value of p1 from multiple input. Is this valid or not?
Many thanks, for the help
tosca_definitions_version: tosca_simple_yaml_1_2
data_types:
data_type_1:
derived_from: tosca.datatypes.Root
properties:
child1:
type: string
child2:
type: string
node_types:
node_type_1:
properties:
p1:
type: data_type_1
topology_template:
inputs:
complex_input:
type: data_type_1
simple_input_child1:
type: string
simple_input_child2:
type: string
node_templates:
node_template_1:
type: node_type_1
properties:
p1: { get_input: complex_input }
node_template_2:
type: node_type_1
properties:
p1:
child1: { get_input: simple_input_child1 }
child2: { get_input: simple_input_child2 }