search

eForms / eForms

The 2nd consultation on eForms, the update to the EU's procurement standard forms. Scroll down for more information.
20 stars 8 forks source link

BT-all; any; Design for automated presentation #203

Open tinne opened 6 years ago

tinne commented 6 years ago

It would be very convenient if the final specification of eForms had a notational form that allowed for (at least, to the EU wide standard) an automated generation of any form based on it.

Some aspects were already considered in the current forms, but with deficiencies, e.g. label names could change when denoting different kinds of tender or one had to keep to a slash notation, e.g., “the contract / the concession”.

One point where the current forms excel description and PDF form footnotes provide only some help, which cannot really be automatically extracted is field presence and dependent field activation, i.e., answers to “Should this question be posed?” - “If people tick this checkbox, which additional questions must I answer?” - “This is repeatable, but how many times?” - These issues have already been discussed to some extend in the discussions, e.g., https://github.com/eForms/eForms/issues/174#issuecomment-425132744 https://github.com/eForms/eForms/issues/193#issuecomment-429379606

There should be some sort of expression language to describe the logic when a conditional form field is present / active and whether it is mandatory in some context. This should depend on different form fields and / or external conditions (is the notice a PIN? Is this D24? is the jurisdiction {country1, country2, ..., country 7}?) or input. The only exception should be OR / XOR-conditions (field value A or field value B must be given (or both / but not both)).

JachymHercher commented 6 years ago

We are trying to write everything about eForms in a machine readable format, precisely to make it easy to generate forms and rules afterwords. The same is also planned for the business rules.

We will be working on this with @paulakeen, but if you have any ideas on what syntax to use, we would be happy to hear them. (I'm aware of the existence of, for example, https://cucumber.io/, which promises "business-readable specifications testable against code", but we haven't yet had time to explore this properly.)

I'm not sure I understand why OR/XOR conditions should be treated differently than other conditions?

tinne commented 6 years ago

“Why should OR/XOR conditions be treated differently?”

My (somewhat implicit) argument was that the condition dependencies should form a Directed Acyclic Graph, that is, when a rule on BT-X relies on a set of conditions, none of these rules should depend on the value of BT-X, neither directly not transitively (via other conditions).

However, this would exclude a rule like “BT-536 inclusive-or BT-537 must be given “(which boils down to “if BT-536 is not given, enforce a value on BT-537,” and vice versa). So my suggestion was to allow this one case explicitly.