Change to the definition of a Assertion List

In the current declarative structure for JSON tests, we have a concept that
you can nest lists of assertions...

assertionList : [ thing.json, otherThing.json, thirdThing.json, [
anotherThing.json, yetAnother.json] ]

This sort of structure, while nested, does not impose semantics on the item
that is nested.

My proposal is that we actually do not support a nested list.  Instead, we
rely upon my new ConditionObject.  A ConditionObject looks like this:


      { "title": "Condition Object",
        "description": "A pseudo-test that will get a result from the
aggregate of its children",
        "assertionType": "must",
        "expectedResult": "valid",
        "errorMessage": "Error: None of the various options were present",
        "compareWith": "or",
        "assertions": [
          "common/has_context.json",
          "common/has_id.json"
        ]
      }

In this way the nested list itself represents a sort of a test - it has a
result and its subtests have results too.

Frankly, I don't know if any of this is necessary.  But having this
structure means that when something gets nested we can have clear
explanatory text associated with it, an explicit result from the aggregate
of what is nested, etc.

So, the questions:


   1. Has anyone used the nested assertion lists?
   2. If so, would it be relatively easy to change?
   3. If not, do we need any sort of nesting support at all?
   4. If so, is this change acceptable?


-- 
Shane McCarron
Projects Manager, Spec-Ops