Recursive matching rules

[jcasado94]

Given the current specification, I don't see a way to deal with self-contained matching rules -- i.e. matching rules for an object which contains itself as an attribute --, where the depth of the recursion is unknown.

For instance,

[
  {
    "id": "1",
    "elements": [
      {
        "id": "1.1"
      }
    ]
  },
  {
    "id": "2",
    "elements": [
      {
        "id": "2.1",
        "elements": [
          {
            "id": "2.1.1"
          },
          {
            "id": "2.1.2"
          },
        ]
      }
    ]
  }
]

A pseudo-definition for such data structure,

element: { id: string, elements: []element }

This could be solved by enabling nth-level path expressions, so one could specify the matching rules for any "elements" attribute (1). Another solution could be implementing named matching rules and being able to reference them, so that the first-level "elements" would just reference back to a general named matching rule (2).

(1)

"matchingRules": {
	"$.body": {
		"match": "type",
		"min": "1"
	},
	"$.body[*].id": {
		"match": "type"
	},
	"*.elements": { // matches any "elements" attribute in the tree
		"match": "type",
		"min": "1"
	},
	"*.elements[*].id": {
		"match": "type"
	}
}

(2)

"matchingRules": {
	"rules": {
		"elements": {
			"$": {
				"match": "type",
				"min": "1"
			},
			"$[*].id": {
				"match": "type"
			},
			"$[*].elements": {
				"match": "rules.elements" // reference to named rule
			}
		}
	},
	"$.body": "rules.elements" // reference to named rule
}

The problem with (2) is it generates an infinite number of possible rules, so I'm not sure of it's compatibility with your rule-weighting algorithm.

I am not sure if this could be pactified via regexp capturing groups, but in any case, I don't think that's a sustainable option.

[uglyog]

One way to do it would be to use something like the // operator from X-Path. I.e.

{
  "//elements.id": {
    "match": "type"
  }
}

This might be something to address with the V4 RFC

[jcasado94]

Any Idea how would you weigh such matcher?

[uglyog]

It would be weighted on the number of elements that match

[uglyog]

This may be difficult to implement, because the consumer DSLs build up the structure as they go. So while we can define matching rules that can be applied to a subset of the document, I am unsure how the DSLs can be built to accommodate this. Having a DSL that has similar to eachAndAnyChildLike or eachPatternLike, it will only be able to construct the first level.

Pact has to deal with both matching a document as well as generating one.

[uglyog]

I'm removing this from the V4 spec for now, because it needs more thinking.