Enhancements to the ContextAccess extension API - reinventing the wheel?

Hi

I have made a number of enhancements to the ContextAccess API extension (found in Learn -> Examples) for my own use, and wondered about offering them to the community. But first, being new to Bonita I'd like to have my ideas sanity-checked.

Does the following sound useful and reasonable (ie is there an existing wheel I have re-designed?)...

Changes to ContextAccess-1.0.0
19th November 2016

1: Supplying the value "data" to a BDM object name in the task 'context' variable
   causes a full extract of the named BDM data (unfiltered). Eg:
    {
        "somePoolBusinessVariableName": "data"
    }

   Note: Using "*" (instead of "data") also works, if you prefer that syntax.

2: Giving the value "evaluate" as the action for task-local variable name causes
   the expression configured to provide the default value to be re-evaluated, and
   thenew value this re-evaluation generates to be returned. This does NOT change
   the stored value of the variable itself (which is [as normal] computed at the
   time the task is initialized - ie when it becomes "ready"). This means that
   these two entries CAN give different results.
    {
        "taskLocalVariableName": "evaluate"
    }
   and
    {
        "taskLocalVariableName": "data"
    }

   When evaluating the default value expression, the internal variable
   "evaluationFlag" is set to true. This allows the rule to know whether it is
   being called in this manner (because the variable is UNDEFINED in the standard 
   context). This means the groovy code to test it has to look like this. (not
   pretty, but it works) ...

    try { evaluationFlag }
    catch (err) {
        // Do the normal default value generating work
    }
    // otherwise -- do the work expected in "evaluation" context

   This means you can write code in the default value expression of a task-local
   variable which is ONLY executed when called from a "context" API call, and
   so gives a simple way to provide a simple custom "GET" stype API for your
   forms. This also also ideal if you want the expression to return a large
   volume of data which you dont want stored in memory or in the Bonita journal
   DB (this is somewhat different from the way the "transient" flag works, 
   which stores the value in memory until the task completed but not in the DB).

3: The value "task" provides a full dump of the current task structure.
    {
        "anyNameYouLike": "task"
    }

4: The value "process" provides a full dump of the current process structure.
    {
        "anyNameYouLike": "process"
    }

5: Some more new action words give the expected values..
    taskName
    taskDisplayName
    taskDescription
    taskDisplayDescription
    processName

   For example...
    {
        "anyNameYouLike": "taskDisplayName"
    }