Re: [tosca] Proposal for get_property based on discussion in WG on 2019

Hi Tal,

I thought a little about this, and did some small background checkâ

So, we get back to special characters. As it happens, â!â is a reserved character in YAML, but â$â is not.

Coincidentally? your proposed â!â character denotes a tag in yaml, i.e. a type, so

prop1: !mystring car

would mean that car is of âtypeâ mystring. Now, TOSCA uses explicit types, so we donât need the YAML tags for that.

Btw. !! starts a global yaml global tag while ! starts a local tag.

Then the idea is that maybe we could use it for functions e.g. something like:

prop1: { !func get_property: [ â ] }

that is to use !func for functions and as we go on with TOSCA to use !whatever for other stuff if needed:

Thoughts:

â!â is already an escape character in YAML so if you want to have a string starting with â!â then you need to quote it anyway

$ is not a special character in YAML so it would be TOSCA specific if we use it

We could expand it later for other stuff
It kind fits with the âtaggingâ concept in general
Btw â@â is also a reserved keyword in YAML but for âfuture useâ
Iâd rather have a âexpandableâ TOSCA tag character then e.g. to reserve $ for functions

Somebody more versed in YAML should check all the implication with â!â, to be sureâ

BR,

/Calin

From: Tal Liron <tliron@redhat.com>
Date: Tuesday, 1 October 2019 at 15:31
To: Chris Lauwers <lauwers@ubicity.com>
Cc: Calin Curescu <calin.curescu@ericsson.com>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: Re: [tosca] Proposal for get_property based on discussion in WG on 2019_09_17

A long-standing issue for me:

I would also like to propose a special reserved prefix character for function calls. E.g., "$" or "!". So:

{ !get_property: [ ... ] }

The reason should be obvious: as it stands one needs to know all the existing intrinsic functions in order to read a TOSCA source and be sure where there is a function call or just a value of a data type. This will also greatly assist parsers, as they will be able to generate the right error message if it is clear that a function call is intended and the function doesn't exist, etc.

(Puccini allows users to easily create custom functions, something that should probably not be part of the language standard, but that could be acknowledged as a potential feature in the spec.)

tosca message