OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Please help interpreting: policy trigger activity definition syntax: extended notation


Dear TOSCA Experts,

 

the specification---TOSCA v1.3 as well as the 2.0 draft---seems to be self-contradicting in the extended notation in policy trigger activity definitions. Taking call_operation as an example:

 

  1. In section 3.6.23.3 Call operation activity definition, the keynames are, all in the same level: call_operation, operation and inputs, with the type of the call_operation defined as “string or empty”.
  2. In section 3.6.23.3.2.2 Extended notation, the pseudo-example is:

 

- call_operation:

   operation: <operation_name>

   inputs:

     <parameter_assignments>

 

The operation key is indented with 1 space from the call_operation key, meaning that the value of call_operation is a map (not empty).

 

The following example, which seems to be the logical one, conforms to point 2 above but not to point 1:

 

        ..

        triggers:

          - some_trigger:

              event: tosca.interfaces.SomeInterface.some_notification

              action:

                - call_operation:

                    operation: SomeInterface.some_operation

                    inputs:

                      some_parameter: some_value

                      ..

 

The following example conforms to point 1 but not to point 2, seems less logical, and is not in line with the other places in the specs where the extended notation idiom is used:

 

        ..

        triggers:

          - some_trigger:

              event: tosca.interfaces.SomeInterface.some_notification

              action:

                - call_operation:

                  operation: SomeInterface.some_operation

                  inputs:

                    some_parameter: some_value

                    ..

 

Besides call_operation, the same issue is present for the delegate and set_state activities.

 

Which one of the above two examples are to be considered as compliant with the specification?

 

Kind regards,

 

Gábor

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]