You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi all,
while using TOSCA as a modeling basis, I implemented a small tool to parse TOSCA files. Based on this, I wanted to add the following thing to the discussion:
Being more tolerant regarding the syntax might in some cases increase the implementation effort for corresponding tooling. Therefore it might be worth to consider a stricter syntax at some places.
One example: For Requirement Assignments (8.7.2 in TOSCA 2.0 csd06) it is possible to use both the extended syntax, such as:
<requirement_name>:
node: <node_template_name>
or a single-line grammar:
<requirement_name>: <node_template_name>
While it is nice to allow this for writing TOSCA, it slightly increases the implementation effort for tooling. In my case I was using TypeScript and thus had to make a distinction in the code between whether the value is a string or an object for further processing.
So from an implementation perspective, I would argue that it would simplify things, if only the "extended syntax" would be allowed in this case. Also since the difference between the two styles considering the example above is minimal, in my opinion.
The text was updated successfully, but these errors were encountered:
Hi all,
while using TOSCA as a modeling basis, I implemented a small tool to parse TOSCA files. Based on this, I wanted to add the following thing to the discussion:
Being more tolerant regarding the syntax might in some cases increase the implementation effort for corresponding tooling. Therefore it might be worth to consider a stricter syntax at some places.
One example: For Requirement Assignments (8.7.2 in TOSCA 2.0 csd06) it is possible to use both the extended syntax, such as:
or a single-line grammar:
While it is nice to allow this for writing TOSCA, it slightly increases the implementation effort for tooling. In my case I was using TypeScript and thus had to make a distinction in the code between whether the value is a string or an object for further processing.
So from an implementation perspective, I would argue that it would simplify things, if only the "extended syntax" would be allowed in this case. Also since the difference between the two styles considering the example above is minimal, in my opinion.
The text was updated successfully, but these errors were encountered: