Proposal B: this is about providing a simplified wildcard-like matching for use in input schemas

If a designer knows how to use regex effectively then they won't be bothered much by creating a morpher.

So making a simpler matching mechanism will make it easier on less knowledgable users.

An example

|*${abc}/${def}*|

So the bars | are required and mark the beginning and end of a "wildcard expression" (the full value, no prefix, no suffix)
Variables are explicitly present and named in the schema, which is an advantage over the regex in Proposal A
An asterisk would match any number of characters (not greedily)
Any other characters outside of variables would be literal matches
All divisions between literals, asterisks, and variables would be assumed to be on word boundaries.
So if you want to break up a word, you have to use a morpher with regex
This feature would end up using regex underneath

Here is a fuller example (from discussion with Qasim)...

input schema...

{ "device": { "id": "|*/${aid}/*|", "bw": "${bandwidth}" }}

payload...

{ "device": { "id": "CX02DPM 43/DEV-53/aus Orlando", "bw": "1000" }}

resulting variable binding...

${aid} = "DEV-53"
${bandwidth} = 1000

 
Using this "wildcard matching" you can get "DEV-53" bound to "aid" but if you want, say, the "02" out of "CX02DPM", you would need to write a morpher and cannot use this facility. Wildcarding is a simplification of regex and relies on the Regex definition of word boundary to recognize substrings that can be variable values.