/* QA checks/verification */ helper algos

1 files changed, 19 insertions, 0 deletions

diff --git a/GLEP:73.mw b/GLEP:73.mw
index fb9f5ec..e9ae23d 100644
--- a/GLEP:73.mw
+++ b/GLEP:73.mw
@@ -574,6 +574,25 @@ The third rule checks whether the conditions of the later constraint do not enfo
 
 Even though the second constraint causes the first one to start to apply, having ''a'' enabled will also cause the third constraint to apply. Since the third constraint has the same effect as the first one, applying the first one will have no effect (the constraint will be satisfied already) and the second iteration will not be required.
 
+====Helper algorithms====
+The specification also provides helper algorithms to determine the two cases: when a condition can evaluate to true, and when it always evaluates to true. In general, the algorithms are concerned only by ''strong'' enforcements, that is those that are guaranteed to happen.
+
+Therefore, it is assumed that a condition ''can'' evaluate to true unless there is at least one sub-condition that can not evaluate to true. That is, having a condition of the form:
+
+ a? ( b? ( c? ( ... ) ) )
+
+it is assumed that it can evaluate to true unless we explicitly have ''!a'', ''!b'' and/or ''!c'' in the currently enforced flag state. Otherwise, we assume that the flag can have any value and so the condition could be made true with appropriate flag values.
+
+Appropriately, a condition ''always'' evaluates to true only if we know that all sub-conditions will evaluate to true. In the fore-mentioned example this would mean that the current flags would have to explicitly list ''a'', ''b'' and ''c''. Otherwise, we assume that one of the flags can have an opposite value and therefore make the condition evaluate to false.
+
+While determining the effective flags, we are only concerned with the flattened constraints whose conditions always evaluate to true (with the value of flags current to the processed constraint). This is in order to avoid enforcing any flags that may not be enforced in a real use case. Considering the above, it means that the flags that would be enforced by such constraints are left in ''undefined'' state, and do not restrict the constraints following.
+
+As noted in the limitation section, this logic suffers from the limitation that it can not infer complex implications of the constraints such as:
+
+ !a? ( b ) a? ( b )
+
+If the value of ''a'' is undefined at the time of processing, the algorithm will presume that neither of the conditions is guaranteed to be true, and therefore ''b'' will be left in undefined state. However, this is considered an unlikely corner case and is not a major concern.
+
 ==Backwards compatibility==
 
 ===Compliance with the PMS===