Determine Syntax, allowable data types, and allowable operations

[christophertubbs]

Syntax, data types, and operations need to be determined for expressions.

The first stab at syntax was:

{
    "key": "{{expression }}"
}

This indicates that expressions will be found in strings matching the regex (?<=")\s*\{\{\s*(?<expression>.+)\s*\}\}\s*(?="), or any string value starting with any amount of whitespace, encountering "{{" without space between, any amount of whitespace, any characters up to any amount of whitespace followed by "}}", any amount of whitespace until the end of the string, all on one line. The characters that are followed by whitespace prior to "}}" will be a group named 'expression'. For the match of " {{ 28 }}", the value "28" may be reference by the name "expression". There might need to be a check to ensure that there are no \n characters within the expression named group.

The key requirements for syntax are:

• The "expression" group is easy to separate from the indicator for an expression string
• The expression string itself needs to be json serializable and deserializable (meaning no unquoted strings)
• The string itself must use strictly uncommon delimiters such as "{{...}}" or "$(...)". There must be a near-zero risk of confusion between an expression and a real value

Environment variables are questionable. They may become very handy, though they may reveal a security risk as it might allow for the querying of sensitive variables such as passwords

Data types are mostly obvious:

• Booleans
• Strings
• Floats
• Ints

What is not obvious, but needed are datetimes and timedeltas. What is not obvious, either, are how to represent them. Any early stab at indicating a timedelta was via timedelta(hours=1). It looks reasonable, but also looks like a function call and this should in no way be able to invoke code as it may reveal a vital security flaw. Something like any pattern matching the iso-8601 standard for durations (PT1H for example) might work to indicate a duration. The regex for that might be r"\s*(?<=P)(?P<days>\d+D)?(T(?P<hours>\d+H)?(?P<minutes>\d+M)?(?P<seconds>\d+S)?)?". We can only support days, minutes, and seconds for a duration/timedelta. We also need to be able to indicate that what looks like a duration isn't one. Something like casting like STRING PT1H might be enough to indicate that everything following STRING is a string and not to be interpreted as anything else.

Operations should be fairly straight forward unless a use case for something else is determined. We probably only need to handle addition, subtraction, multiplication, division, and possibly modulus.

The door should be left over for nested expressions, but is too large for the given scope.