Hi,
I think there is a difference between condition clauses and constraint clauses and it should stay so. Actually
condition clauses use constraint clauses for each property or attribute they apply to.
More comments inline in the mail below.
BR,
/Calin
From: "Katzman, Anatoly" <
anatoly.katzman@intl.att.com>
Date: Tuesday, 18 December 2018 at 14:47
To: 'Chris Lauwers' <
lauwers@ubicity.com>, Calin Curescu <
calin.curescu@ericsson.com>, "NOSHPITZ, CLAUDE" <
cn5542@att.com>, "'
alex.vul@intel.com'" <
alex.vul@intel.com>, Arturo Martin De Nicolas <
arturo.martin-de-nicolas@ericsson.com>, "'
lishitao@huawei.com'"
<
lishitao@huawei.com>, "'
ljlamers@vmware.com'" <
ljlamers@vmware.com>, "'
mrutkows@us.ibm.com'" <
mrutkows@us.ibm.com>, "'
Paul.Lipton@ca.com'" <
Paul.Lipton@ca.com>, "'
priya.g@netcracker.com'" <
priya.g@netcracker.com>, Steve Baillargeon <
steve.baillargeon@ericsson.com>,
"'
thinh.nguyenphu@nokia.com'" <
thinh.nguyenphu@nokia.com>, "'
dmytro.gassanov@NetCracker.com'" <
dmytro.gassanov@netcracker.com>, "'
don.deel@netapp.com'" <
don.deel@netapp.com>, "'
dpalma@vnomic.com'" <
dpalma@vnomic.com>, "SHADMI, DAVID" <
ds200p@att.com>, "'
hsurti@cisco.com'"
<
hsurti@cisco.com>, "'
ifat.afek@alcatel-lucent.com'" <
ifat.afek@alcatel-lucent.com>, "'
JDurand@us.fujitsu.com'" <
JDurand@us.fujitsu.com>, "'
jeremy@gigaspaces.com'" <
jeremy@gigaspaces.com>, "'
jim.hunter@ca.com'" <
jim.hunter@ca.com>, "'
jpackett@us.ibm.com'"
<
jpackett@us.ibm.com>, "'
kraman@redhat.com'" <
kraman@redhat.com>, "'
luca.gioppo@csi.it'" <
luca.gioppo@csi.it>, "'
rpenta@redhat.com'" <
rpenta@redhat.com>, "'
xavier.degenne@fastconnect.fr'" <
xavier.degenne@fastconnect.fr>, "'
zhao.huabing@zte.com.cn'" <
zhao.huabing@zte.com.cn>
Cc: "'
tosca@lists.oasis-open.org'" <
tosca@lists.oasis-open.org>
Subject: RE: Enhancements to the TOSCA data filtering abilities
PS:
>>>>
What are these some tables? Well, the Node filter definition (3.6.5) will gain significantly from the change. So in the Node Filter Definition section, I would add the condition keyname
with a reference to the condition clause definition, and this is in addition to already existing keynames properties and capabilities .
This is the part where conditions clauses come in. Regarding properties
and capabilities , I think we should deprecate them and use Anatoly s third proposal based on the format of the get_property
function.
I am less sure about other tables, such as Property filter definition (3.6.4) , Property definition (3.6.10), Schema definition (3.6.9), Data type (), and I probably forgot
a few. If we decide to change them in 1.3, than another question is whether to redefine the existing constraints keyname or introduce the less confusing condition instead?
Here we need to keep the constraint clauses since they refer to only on ONE property (the one that is defined).
Condition clauses cannot be used.
I also think that or and not need to be introduced here since we cannot use the condition clauses.
<<<<
I took a second look on the grammars of these four tables, and everything looks safer in the morning