[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Datatype definition with an empty base type?
Hi, regarding the idea of the “final” attribute on types: in fact, it is not so much the type definition itself that needs to be “final” but it is the point where it is used. I.e. in the
present example, we would have it in the interface type definition:
tosca.interfaces.nfv.Vnflcm
derived_from: tosca.interfaces.Root
instantiate:
description: Invoked upon receipt of an Instantiate VNF request
inputs:
additional_parameters:
type: tosca.datatypes.nfv.VnfOperationAdditionalParameters
required: false
final: false
.. and the referred data type could simply be empty:
tosca.datatypes.nfv.VnfOperationAdditionalParameters:
derived_from: tosca.datatypes.Root Note that in order to enable the whole chain of extensions (from the VNF node type down to the additonal_parameters), we need further “non-final” markers:
tosca.interfaces.nfv.Vnflcm
derived_from: tosca.interfaces.Root
instantiate:
final: false
description: Invoked upon receipt of an Instantiate VNF request
inputs:
additional_parameters:
type: tosca.datatypes.nfv.VnfOperationAdditionalParameters
required: false
final: false
.. and:
tosca.nodes.nfv.VNF:
derived_from: tosca.nodes.Root
properties:
..
interfaces:
Nfv:
type: tosca.interfaces.nfv.Vnflcm
final: false (the same applying to the
configurable_properties and
modifiable_attributes properties, not shown for brevity). Greetings, Gábor From: Marton, Gabor (Nokia - HU/Budapest)
Hi Arturo, Chris, Shitao and Thinh, on Arturo’s concern (“how can we preclude that in a VNFD service template, any property is replaced by a property of a derived,
richer type”), we could propose a “final” keyword---or something equivalent---in the TOSCA grammar for this purpose, e.g.:
tosca.datatypes.nfv.VnfOperationAdditionalParameters:
derived_from: tosca.datatypes.Root
final: false i.e. for all types with final=true, derivation would be forbidden. Until such a tool gets available in TOSCA, i.e. for the short term in SOL001, we could explicitly define---in normative
text---the types that are meant for extension and the ones that are not. For preventing template authors from messing up derived types completely, it would be worth setting the rules of type extension in the TOSCA specs. E.g.: A derived type must extend the base type in such a way that it remains substitutable for the base type. More specifically:
i. A string property may not be overridden with an integer property or with a complex property of the same name.
ii. A complex property based on a data type may be overridden with a property of type derived from that data type.
I believe that for introducing VNF-specific constructs on the
type level in the VNFD (i.e. modifiable attributes, configurable properties, additional parameters to operations), the best approach is to derive from existing types, because not deriving would make the VNFD even less validatable. I.e. we need to introduce
the new constructs at well-defined “extension points”, and the only tool for this to my knowledge is type extension. Greetings, Gábor From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Lishitao Yes, from TOSCA grammar perspective this should be fine, but as we discussed during SOL#66 Piscataway meeting , it is better to avoid this usage. It will
introduce many unexpected influences for standard. 发件人:
tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
代表
Arturo Martin De Nicolas Hi Thinh, No one doubted that it is possible to define an empty base data type and derive other data types from it. The point is that in the interface type definition in SOL001 we will have properties of this empty data type. But any interface defined in any SOL001 compliant VNFD service template
will have those properties not from the base empty type but from the derived type. Is there a way to express that in the schema? Otherwise how can we preclude that in a VNFD service template, any property is replaced by a property of a derived, richer type? BR, Arturo From:
tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Chris Lauwers Yes, I don’t see any issues with this.
Chris Sent from my iPhone
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]