[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tosca] key_schema in TOSCA 1.3?
Hi, I agree that all the TOSCA entity names should be strings (keywords are strings by definition) and should be syntax checked. BR, /Calin From: <tosca@lists.oasis-open.org> on behalf of Tal Liron <tliron@redhat.com> I thought of another potential concern due to this often-overlooked YAML feature. TOSCA parsers written in un-typed languages (Python, Ruby) may very well forget to check that names of types, properties, operations, etc., are strings. Since these are provided as YAML keys in the TOSCA syntax, it may be just assumed that
the YAML parser did the right thing and made sure that they are strings. But it might not be so. For example, before I implemented the check this would be allowed in Puccini (after I added support for complex key maps): node_types: But this legal YAML should be illegal in TOSCA, because the "type" keyword in a node template (and other places, such as "node" in requirements) is defined as a string. It would make sense, then, to generalize and specify in the spec that
all entity names should be strings. (This also means no integers, floats, etc.) It makes sense that a name would be a string and this would clarify consumption of TOSCA by orchestrators and other tools. E.g., in an instance model a database column for
a name in could be confidently defined as type "text". This should also apply to property/parameter/input names. E.g.: node_types: While it could be argued that property names are arbitrary, this could lead to unnecessary complexity in other parts of the language. E.g. the "get_property" function would need to support complex property names. And again, tools may want
to store these names predictably. For consistency, then, we could require all such names (to be clear, they are not
entity names) to also be strings. To phrase it conversely, the only place in TOSCA where complex YAML keys should be allowed is in the schemas of complex data types, where TOSCA provides an explicit feature (key_schema) to specify it. Implementators take note! We should be very careful to avoid automatic translation of non-strings to strings in such cases (some dynamic languages do this automatically for you) because each programming language would do it differently,
leading to incompatibilities between TOSCA implementations. Even a number (integer, float) could become a different string in different programming languages. So, this should be illegal in TOSCA (though it is legal YAML): node_types: But this should be fine TOSCA: node_types: On Wed, Sep 11, 2019 at 5:52 PM Chris Lauwers <lauwers@ubicity.com> wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]