[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Enhancements to the TOSCA data filtering abilities
|
Hi, There are 3 chinks we must iron out:
condition: - or:
- port: { equal: 80 } - [compute, mem_size] : { greater_or_equal: 2GB } Unless we change the node_filter definition in section 3.6.5 that has to start with either âpropertiesâ of âcapabilitiesâ keyword. To do that we could deprecate the use of the previous 2 keywords
and add the possibility to use conditions in the new form. Btw. Iâm in favor to adopt Anatolyâs third proposal also for the potential future addition of special keywords in the list e.g
[compute, *, mem_size] which could evaluate to: Somewhere in the structure of the capability compute if there is a âmem_sizeâ
property then it should have the following constraintâ
BR, /Calin From: "Katzman, Anatoly" <anatoly.katzman@intl.att.com> 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]