Can "match" syntax / semantics be simpler?

[bradh]

In the proposed resolver spec, for match, the intepretation of the pattern is "The match pattern is evaluated as a regular expression using XPath regular expression syntax".

I'm a bit concerned that this is too complex to implement completely unless you have a fully conformant XPath 2.0 engine. In particular, some of the backtracking and group matching options look hard to emulate completely, and really hard to test.

I think I'd like something simpler, like the XML Schema regexp syntax, or even simpler than that (just a basic glob operation, perhaps). It could also be worth reviewing whether implicit anchoring is worth considering (i.e. it always has to match the whole control, like XML Schema does).

This is based on what we usually mean - "I want all of those controls without needing to identify them all". So something like <match pattern="au-*"/> would probably be enough.

We don't really need subtraction (because we have <exclude>), we don't absolutely need alternation (because match can be repeated if you want a few different prefixes), we almost certainly don't need backtracking, grouping or anchors. It might be nice to have ranges and single character match, but that could be enough.

[wendellpiez]

I agree with this concern. Requiring XPath semantics is a problem. A simple glob syntax would be easier to use and less problematic for anyone not using the XML stack.

[david-waltermire]

With regex communities always get into the discussion of which regex to use. XMLSchema regex is a good minimal choice. I believe it is compatible in its reduced feature set with pcre.

My guess is XMLSchema regex is also close to being compatible with the regex from ECMA 262, which is used in JSON Schema. I notice that negative and positive lookahead is supported here, but not in XML Schema.

Perhaps we need to specify against the common set of features supported by XML Schema and JSON Schema? This may involve us defining that allowed subset.

[david-waltermire]

Talked with the OSCAL model review community about this today. There was consensus on the call to simplify matching to support only a [glob wildcard](https://en.wikipedia.org/wiki/Glob_(programming) pattern.

We can consider adding a regex matching feature in the future, when we have more time to talk through the regex flavor to specify.

[wendellpiez]

Profile resolution to be merged into branch #882 now supports glob syntax in matching/@pattern.