Hi Ann,,

The "ConditionFilter" component will try all combinations of your Condition Context (so the entries in the Publication Manager > Conditions tab) to make the @ishcondition valid. If it cannot make it valid (so TRUE) then the xml scope of the @ishcondition element is conditionally filtered out. So implicitly there is only an include-action when the condition is valid, as mentioned in a similar question of yours we do not have flag-action or exclude-action as DITAVAL has. The product does however offer a way richer set of boolean logic, version-number handling with all kinds of compare operators up to an IN-clause.

The advice is to prefer the positive writing of conditions as the alternative has several downsides over time. Consider the following example

1. You wrote @ishcondition="not(COOLING=AIR)"
2. Your Condition Context says "COOLING=AIR"
3. Conditional filtering cannot make the @ishcondition evaluate to TRUE, so it gets excluded
4. However, if your organization adds a second flavor of COOLING like COOLING=WATER ... then your @ishcondition="not(COOLING=AIR)" suddenly will be evaluated to @ishcondition="not(WATER=AIR)" which technically is TRUE... so in practice you'll have to adapt all content using that condition, which is not something you want to do.

In this example I wrote not(...), you could also write condition name "notCOOLING" and think about scenarios

Hope this gets you going on a Friday :-)

-Dave

Hi Ann,,

The "ConditionFilter" component will try all combinations of your Condition Context (so the entries in the Publication Manager > Conditions tab) to make the @ishcondition valid. If it cannot make it valid (so TRUE) then the xml scope of the @ishcondition element is conditionally filtered out. So implicitly there is only an include-action when the condition is valid, as mentioned in a similar question of yours we do not have flag-action or exclude-action as DITAVAL has. The product does however offer a way richer set of boolean logic, version-number handling with all kinds of compare operators up to an IN-clause.

The advice is to prefer the positive writing of conditions as the alternative has several downsides over time. Consider the following example

1. You wrote @ishcondition="not(COOLING=AIR)"
2. Your Condition Context says "COOLING=AIR"
3. Conditional filtering cannot make the @ishcondition evaluate to TRUE, so it gets excluded
4. However, if your organization adds a second flavor of COOLING like COOLING=WATER ... then your @ishcondition="not(COOLING=AIR)" suddenly will be evaluated to @ishcondition="not(WATER=AIR)" which technically is TRUE... so in practice you'll have to adapt all content using that condition, which is not something you want to do.

In this example I wrote not(...), you could also write condition name "notCOOLING" and think about scenarios

Hope this gets you going on a Friday :-)

-Dave