[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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_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:
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_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 property 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 property 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 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:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]