[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Enhancements to the TOSCA data filtering abilities
|
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> 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
😊. Now I do want to extend the change to these clauses in 1.3. In all four clauses, I suggest to keep using the keyname âconstraintsâ
to start the condition definition. From: Katzman, Anatoly
Mine comments added. From: Chris Lauwers <lauwers@ubicity.com>
Comments in-line From: Calin Curescu <calin.curescu@ericsson.com>
Hi, I agree that we should use
condition clauses in the node_filter instead of constraint clauses. This will allow us to put an âorâ or a ânotâ in front of several attributes.
Moreover, by using the âdirect assertion definitionâ when specifying it, the condition clause becomes undistinguishable from a constraint clause.
Actually, to be technical correct, I would rephrase this as follows:. The syntax for condition clauses looks as follows (assuming we deprecate the âassertâ keyword): condition_clause: and_clause | or_clause | not_clause | list of assertion_clause or_clause : âor:â + list of condition_clause and_clause: âandâ + list of condition_clause not_clause: ânotâ + list of condition_clause assertion_clause: <property_name:> + list of constraint_clause The syntax for property filter clauses looks as follows: property_filter: <property_name:> + list of constraint_clause What this means, then, is that the assertion clause and the property filter clause look exactly the same (assuming again that we deprecate the âassertâ keyword). If in addition, we allowed Boolean
operators in node_filters, then a node filter would effectively consist of a condition clause. Constraint clauses would still look different. [AK] Right. A condition clause is generally a complex thing that can include nested conditions, while a constraint clause specifies a primitive predicate. A constraint is so primitive that
even the value it is applied to is specified outside of it. constraint_clause: greater_than | less_than | ...
Which means that all the existing specifications stay valid. We just add the possibility to put an âandâ âorâ or ânotâ before several properties/attributes, from now on.
Unless anyone objects, I will obsolete the âassertâ keyword in condition clauses. [AK] I objected in the past, because I thought it would be useful in the future for applying custom predicates. Now I withdraw my objections.
Also within the constraint clause it is useful to have âorâ and ânotâ to be able to express better constraints. This is simple, just by adding the âandâ, âorâ, and ânotâ to the constraints
keyword tables. Again, this will extend the constraint clause, with all that is already written staying valid. [AK] I think we still need the constraint clause (3.6.3) in its existing form, at least to use it (as part of the property assertion clause) to terminate recursively defined conditions.
What you call a âbetter constraintâ is actually a condition clause (3.6.25), so instead of redefining the constraint clause itself, I would change or add references from some of the keyname tables. 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â. 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? Yes, this would be simple to do, but Iâm not sure it adds a whole lot of value. For example, letâs look at the following example which would become possible with your suggestion: condition: - port:
- or - { equal: 80 } - { equal: 431 } [AK] This one will not work. After a property name, the grammar expects a list of primitive constraints, not a condition. This logic could already be expressed without your suggestion as follows: condition: - or:
- port: { equal: 80 } - port: { equal: 431 } [AK] I really like this new syntax, it is really powerful. It allows to combine multiple properties and sub-properties in one condition. Here is an even better example: condition: - or:
- protocol: { equal: http } - port: { equal: 80 }
- protocol: { equal: https } - port: { equal: 431 } Would we create confusion by giving template designers two different ways to accomplish the same thing? The only thing that we still cannot do within a node_filter is to have an âorâ between normal properties and properties within a capability definition. But this is a small price
to pay for backwards compatibility. Yes, but that could be accomplished if we adopted Anatolyâs 3rd proposal, as follows. Letâs assume a node has a âportâ property and a âcomputeâ capability. We could create a logic _expression_
as follows: condition: - or:
- port: { equal: 80 } - [compute, mem_size] : { greater_or_equal: 2GB } [AK] Yes! The changes in the document should be immediate and straightforward. I could help to write it. BR, /Calin |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]