IF ... THEN ... ELSE using XML

I have a program that uses XML-formatted rules to create executable code for runtime. I have to define some actions and logical constructions using my own dialect. I have OR, AND, and NOT, and now I need to implement IF..THEN..ELSE.

I am trying to find a syntax that will make sense, and here is what I still have:

<IF id='if-1'> <TIME from="5pm" to="9pm" /> </IF> <THEN id='if-1'> <...some actions defined.../> </THEN> <ELSE id='if-1'> <...other set of actions defined here.../> </ELSE> 

If it’s hard for me to read, but I don’t see a cleaner way to imagine it without doing too much nesting. Anyone have a suggestion? (not using XML, this is not an option at this point in time :))

+7
source share
9 answers

I personally think that if / then / else needs to be somehow connected.

 <IF something> <some actions> <THEN something> <some actions> </THEN> <ELSE something> <some actions> </ELSE> </IF> 
+6
source

Perhaps another way to code conditional constructs in XML:

 <rule> <if> <conditions> <condition var="something" operator="&gt;">400</condition> <!-- more conditions possible --> </conditions> <statements> <!-- do something --> </statements> </if> <elseif> <conditions></conditions> <statements></statements> </elseif> <else> <statements></statements> </else> </rule> 
+6
source

At the same time, faced with a similar problem, I decided to switch to a generalized solution like "switch ... case ... break ... default" along with a set of arm-style commands with conditional execution. A user interpreter using the nesting stack was used to analyze these "programs." This solution completely eliminates identifiers or tags. All my XML elements or “instructions” support the attribute “condition”, which, if it is absent or if it evaluates to true, the instruction of the element is executed. If the "exit" attribute is true and the condition is also true, then the next group of elements / instructions at the same nesting level will neither be evaluated nor executed, and execution will continue with the subsequent element / instruction at the parent level. If there is no "exit" or it evaluates to false, the program proceeds to the next element / instruction. For example, you can write this type of program (it will be useful to provide a noop instruction), and the mechanism / instruction for assigning values ​​and / or expressions for "variables" will be very convenient):

 <ins-1> <ins-11 condition="expr-a" exit="true"> <ins-111 /> ... </ins11> <ins-12 condition="expr-b" exit="true" /> <ins-13 condition="expr-c" /> <ins-14> ... </ins14> </ins-1> <ins-2> ... </ins-2> 

If expr-a is true, then the execution sequence will be:

 ins-1 ins-11 ins-111 ins-2 

if expr-a is false and expr-b is true, then this will be:

 ins-1 ins-12 ins-2 

If both expressions expr-a and expr-b are false, we get:

 ins-1 ins-13 (only if expr-c evaluates to true) ins-14 ins-2 

PS. I used "exit" instead of "break" because I used "break" to implement "breakpoints". Such programs are very difficult to debug without any breakpointing / tracing mechanism.

PS2. Since I had similar conditions for the date, as your example, along with other types of conditions, I also implemented two special attributes: "from" and "to", which should also be evaluated as true if they were present as a "condition" , and which used special fast logic for checking the date and time.

+4
source
 <IF id='if-1'> <CONDITION> <TIME from="5pm" to="9pm" /> </CONDITION> <THEN> <...some actions defined.../> </THEN> <ELSE> <...other set of actions defined here.../> </ELSE> </IF> 

It has become easier to read. There's more nesting there, but if anything that helps with readability?

+2
source

I do not think that you can construct an if-then-else construct without considering the design for other constructs. I consider it a good principle that every expression should be an element, and its subexpressions should be children. Then questions arise about whether the element name should reflect the type of expression, or its role relative to the parent. Or you can do both:

 <if> <condition> <equals> <number>2</number> <number>3</number> <equals> <condition> <then> <string>Mary</string> </then> <else> <concat> <string>John</string> <string>Smith</string> </concat> </else> </if> 

But sometimes you can leave with a design that omits the role names (condition, then another) and relies on the positional value of the elements relative to their parent. It depends a little on how you want to keep it concise.

+1
source

I think you should keep in mind that your XML is processed by the machine, not by humans, so it should be read only for the machine.

In other words, I think you should use any XML schema necessary to make the parsing / processing of rules as efficient as possible at runtime.

As for your current schema, I think the id attribute should be unique for each element, so maybe you should use a different attribute to fix the relationship between your IF , THEN and ELSE elements.

0
source
 <IF id="if-1"> <TIME from="5pm" to="9pm" /> <ELSE> <something else /> </ELSE> </IF> 

I don’t know if this has any meaning for anyone else, or if it is really useful in your program, but I would do it as follows.

My point: you need to have everything related to your "IF" inside your IF tag, otherwise you will not know that ELSE belongs to what IF. Secondly, I would skip the THEN tag because it always follows IF.

0
source

Personally, I would prefer

 <IF> <TIME from="5pm" to="9pm" /> <THEN> <!-- action --> </THEN> <ELSE> <!-- action --> </ELSE> </IF> 

This way you don't need the id attribute to bind IF , THEN , ELSE tags

0
source
 <IF> <CONDITIONS> <CONDITION field="time" from="5pm" to="9pm"></CONDITION> </CONDITIONS> <RESULTS><...some actions defined.../></RESULTS> <ELSE> <RESULTS><...some other actions defined.../></RESULTS> </ELSE> </IF> 

Here I take it upon myself. This will allow you to have several conditions.

0
source

All Articles