[JBoss JIRA] (DROOLS-1962) [DMN Editor] Decision service
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1962?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1962:
----------------------------------
Fix Version/s: (was: 7.5.0.Final)
> [DMN Editor] Decision service
> -----------------------------
>
> Key: DROOLS-1962
> URL: https://issues.jboss.org/browse/DROOLS-1962
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Trivial
> Labels: reported-by-qe
>
> "In DRD it is rounded rectangle that surrounds all of the encapsulated decisions in the service. The inputs to the service are defined by all of the information requirements leading into the rounded rectangle. The outputs of the service are the decisions shown above the straight line bisecting the rounded rectangle. If there is no such line, all encapsulated decisions are exposed in the service output." cited form DMN Method and Style, Chapter 3, Decision Requirements
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (DROOLS-1970) [DMN Editor] Hit policies
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1970?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1970:
----------------------------------
Fix Version/s: (was: 7.5.0.Final)
> [DMN Editor] Hit policies
> -------------------------
>
> Key: DROOLS-1970
> URL: https://issues.jboss.org/browse/DROOLS-1970
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.1.0.Beta2
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Labels: reported-by-qe
>
> Implement hit policies of the DMN Specification:
> - Unique (Single hit policy)
> -- No overlap is possible and all rules are disjoint. Only a single rule can be matched. This is the default.
> - First (Single hit policy)
> -- Multiple (overlapping) rules can match, with different output entries. The first hit by rule order is returned (and
> evaluation can halt). This is still a common usage, because it resolves inconsistencies by forcing the first hit.
> However, first hit tables are not considered good practice because they do not offer a clear overview of the decision
> logic. It is important to distinguish this type of table from others because the meaning depends on the order of the
> rules. The last rule is often the catch-remainder. Because of this order, the table is hard to validate manually and
> therefore has to be used with care.
> - Priority (Single hit policy)
> -- Multiple rules can match, with different output entries. This policy returns the matching rule with the
> highest output priority. Output priorities are specified in the ordered list of output values, in decreasing order of
> priority. Note that priorities are independent from rule sequence.
> - Any (Single hit policy)
> -- There may be overlap, but all of the matching rules show equal output entries for each output, so any match can
> be used. If the output entries are non-equal, the hit policy is incorrect and the result is undefined.
> - Output Order (Multiple hit policy)
> -- returns all hits in decreasing output priority order. Output priorities are specified in the ordered list of
> output values in decreasing order of priority.
> - Rule Order (Multiple hit policy)
> -- Returns all hits in rule order. Note: the meaning may depend on the sequence of the rules.
> - Collect ( Multple hit policy with the aggregation operators +, >, < and #)
> -- Returns all hits in arbitrary order. An operator (‘+’, ‘<’, ‘>’, ‘#’) can be added to apply a simple function to the outputs. If no operator is present, the result is the list of all the output entries. Collect operators are:
> a) + (sum): the result of the decision table is the sum of all the distinct outputs.
> b) < (min): the result of the decision table is the smallest value of all the outputs.
> c) > (max): the result of the decision table is the largest value of all the outputs.
> d) # (count): the result of the decision table is the number of distinct outputs.
> Other policies, such as more complex manipulations on the outputs, can be performed by post-processing the
> output list (outside the decision table).
> Please ensure that the HIT policy can be changed whenever during modeling the decision table.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (DROOLS-1942) [DMN Editor] InformationItem's "Name" is always the same as the containing node
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1942?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1942:
----------------------------------
Fix Version/s: (was: 7.5.0.Final)
> [DMN Editor] InformationItem's "Name" is always the same as the containing node
> -------------------------------------------------------------------------------
>
> Key: DROOLS-1942
> URL: https://issues.jboss.org/browse/DROOLS-1942
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
>
> Whilst an {{InformationItem}} Node has a "Name" its value is always the same as the containing Node's "Name" (for {{InputData}}, {{Decision}} and {{BusinessKnowledgeModel}}). {{ContextEntry}}'s "Name" are not the same as outer most node's "Name" (as a {{ContextEntry}} is contained within a {{Context}} and not directly in a node itself).
> It is proposed that this synchronization should be handled in the "Stunner to (org.kie) DMN model" marshalling. Therefore we need to remove the "Name" {{@FormField}} from {{InformationItem}}.
> [~tari_manga] [~tirelli] Please confirm.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months