Issue #146: Hierarchical ruleId amendment

["Larry Golding (Myriad Consulting Inc)" <v-lgold@microsoft.com>]

Just so you can see the editing magic happen, here’s the change corresponding to the amendment we approved at TC #32 this morning (from the raw notes): “Note the change in constraint between result.ruleId and rule.ruleId [sic – should be rule.id]: latter has to be component-wise prefix of former.”

 

Before:

If ruleIndex and ruleId are both present, then the value of the id property (§3.40.3) of the rule object specified by ruleIndex SHALL equal the value of ruleId.

 

After:

 

If ruleIndex and ruleId are both present, then the value of the id property (§3.40.3) of the rule object specified by ruleIndex either SHALL equal the value of ruleId , or it SHALL equal a substring of ruleId that starts at the beginning of the string and ends before the last forward slash.

EXAMPLE 2: In this example, the first result object is valid because its ruleId property equals the id property of the rule object specified by ruleIndex (which we will refer to as theRule). The second result object is also valid because theRule.id equals all but the last component of ruleId. The third result object is invalid because its theRule.id is not a “component-wise” prefix of ruleId.

{                            # A run object (§3.13).

  "results": [               # See §3.13.14.

    {                        # A result object (§3.22).

      "ruleId": "abc/def",   # See §3.40.3.

      "ruleIndex": 0,

    },

    {

      "ruleId": "abc/def/ghi",

      "ruleIndex": 0

    },

    {

      "ruleId": "abc/defg",  # INVALID: Not a "component-wise" prefix of

      "ruleIndex": 0         #   theRule.id.

    }

  ],

  "resources": {             # See §3.13.15.

    "rules": [               # See §3.39.3.

      {                      # A rule object (§3.40).

        "id": "abc/def",    # See §3.40.3.

        ...

      },

      ...

    ]

  }

}

 

Larry