DMN/FEEL in Python

[CoolGuy]

Is there any implementation of decision modeling and notation standard from OMG i Python? Maybe only a subset like decision tables definition and execution? Or possibly FEEL (friendly enough expression language) in Python?

[Larz60+]

I can't vouch for it, but found: http://www.opensourcerers.org/capture-yo...-with-dmn/

[CoolGuy]

Thank you, but this seems like Java implementation.

I can't vouch for it, but found: http://www.opensourcerers.org/capture-yo...-with-dmn/

[russellmcdonell]

I have had a go at this. Currently just a repository (two actually) at github
https://github.com/russellmcdonell/pyDMNrules
Reads an Excel workbooks for the rules but need my implementation of S-FEEL
https://github.com/russellmcdonell/pySFeel
which has been implemented using the sly module (lex and yacc for Python).
I think that both repositories are public and would appreciate feedback.
If there's enough interest I'll try and turn them into pip installable modules and some documentation.
P.S. - this has been implemented using Python 3.8, but I suspect is should work with older version of Python 3. However it is definitely not Python 2 compatible (as sly is not Python 2 compatible).

[mengwong]

If there's enough interest I'll try and turn them into pip installable modules and some documentation.

Nice work! I recently conducted a poll about adding DMN support to a number of popular languages and editors.

In my informal poll, Python topped the list: https://twitter.com/mengwong/status/1264118536064004096

To date, DMN implementations have involved a GUI saving to XML (either DMN or XLSX).

My twist: I'd like to propose DMN as Markdown tables, inline.

So the Python interface would be something like this:

var whatdish = dmnmd("""
| U | Season               | Guest Count | Dish (out)                   | # Annotation  |
|---|----------------------|-------------|------------------------------|---------------|
| 1 | Fall                 | <= 8        | Spareribs                    |               |
| 2 | Winter               | <= 8        | Roastbeef                    |               |
| 3 | Spring               | <= 4        | Dry Aged Gourmet Steak       |               |
| 4 | Spring               | [5..8]      | Steak                        |               |
| 5 | Fall, Winter, Spring | > 8         | Stew                         |               |
| 6 | Summer               | -           | Light Salad and a nice Steak | Hey, why not? |
""");

And then whatdish("Fall",4) returns "Spareribs"

Reinventing the wheel slightly, I spent the weekend writing a markdown table parser and FEEL evaluator in Haskell, so I know it can be done … as you've shown with your XLS parser and S/FEEL evaluator.

If this takes off we can imagine extending various IDEs' python modes to do markdown table editing as a submode sort of thing.

Thoughts?

[russf]

Interesting to see DMN in Python.
And I can appreciate the desire for markdown tables.

[russellmcdonell]

I did turn pyDMNrules into package and post it to PyPi. It can be installed with "pip install pyDMNrules".
The only limitations are you have to use 'true and 'false (not the Excel equivalents of TRUE and FALSE) and you can't declare functions.
As for MarkDown - the problem is the semantic boundaries between rows/columns.
DMN uses double vertical bar borders to show then end of input columns/start of output columns and the end of output columns/start of annotation columns. Similarly double horizontal borders mark then end of headings and start of rules, which seem irrelevant, until you realize that pyDMNrules has to be able to detect column based, row based and cross-tab rules tables - ouch.
The other advantage of Excel (well any spreadsheet - we can adapt to Google Sheets if need be) is that you can specify dates as 17-Jan-2020 and any other local date/datetime format that you like. pyDMNrules get passed something that is already a Python internal date/datetime object - so pyDMNrules does not parse date/datetime cells. Now pyDMNrules will parse a string in the S-FEEL format, but using MarkDown would force everyone to become comfortable with this method of representing dates/datetimes.

[russellmcdonell]

My twist: I'd like to propose DMN as Markdown tables, inline.

I don't have a problem with MarkDown. It the delimiting inputs to output that a bit worrying. Having '(out)' after every output name may be prone to errors. And it could lead people to mixing input and outputs (so adding some more inputs to the end of the table when extending the rules). That would make things a tad more challenging and possible make these tables less clear.

Perhaps we could pinch an idea from DMN and use an empty column (||) as the delimiter between inputs and outputs. Then you have to support vertical rules tables, as well as horizontal rules tables. And crostab rules tables. Perhaps an empty row would work here
--------
--------
And I like the idea of prepending annotations with the # character.
Then there's the hierarchy of the rules - which rules are to be run. A table of inputs or outputs followed by a rules name. That way an input can dictate which rules are to be run. Or an output of an earlier decision can turn on/off subsequent rules.

And finally there's the unit test table. But all of this can be done. Would we take it to OMG? Not sure.

[russellmcdonell]

pyDMNrules has a controlling 'Decision' table, which has optional input columns, but the 'output's are the names of decision tables. The input value(s) determine which decision tables get run. And yes, the output of a decision table can be an input that modifies which decision tables are run. So you have, effectively, a runtime configurable decision. However pyDMNrules also reserves the output column name of 'Execute' and 'outputs' in an Execute column must be the names of decision tables. So any decision table can chose which other decision tables are to be executed. Further more, a decision table can 'Execute' itself. So one decision table can set a loop counter (to say zero) and call a 'loop' decision table. The 'loop' decision table would check if the loop counter was less than some limit. If it is, it 'Execute's a loop body decision table, increments the loop counter and then 'Execute's the 'loop' decision table,thus looping around. If the loop has reached the limit, then the 'loop' decision table executes no rules. The 'loop' decision table would be a 'R' - RULES ORDER decision table. I believe DMN 1.4 will define an ability to embed and decision table within a decision table.