The problem is, we are passing in a contact template to the matcher.
Thus it needs to follow field definition of the contact template.
We discussed and started implemeting an approach to let a Matcher return typed data rules it offers.
Then the matcher would also need to tell us what bundles / contact types it supports... and possibly also offer a factory to provide a contact template to fill with data.
Then matchers can offer any typed data fields they want and we can pass in data...
If a matcher offers to match across multiple bundles, the contact template possibly can skip the bundle. So this might be an optional selection and the matcher needs to support enumerating both field definition for all bundles or for a specific bundle.
(as a result, whoever calls the matcher doesn't need to create a contact template on its own and the calling code has no direct use of contact field definition code at all.)
The problem is, we are passing in a contact template to the matcher. Thus it needs to follow field definition of the contact template. We discussed and started implemeting an approach to let a Matcher return typed data rules it offers. Then the matcher would also need to tell us what bundles / contact types it supports... and possibly also offer a factory to provide a contact template to fill with data.
Then matchers can offer any typed data fields they want and we can pass in data... If a matcher offers to match across multiple bundles, the contact template possibly can skip the bundle. So this might be an optional selection and the matcher needs to support enumerating both field definition for all bundles or for a specific bundle.