Options for describing *picker semantics

[glyn]

Two options have been considered for defining picker semantics (where a picker is a syntactic element of a child selector):

1. a selector presents a single value to a picker, the picker selects zero or more children of the value, and the resultant nodelist is used in constructing the selector's nodelist, and
2. a picker is a predicate which determines whether any given child of a value is to be selected. A child selector selects those children of its input value for which a picker is true.

Option 2 was rejected since a *picker was not thought to be a suitable software component because of its interface and its performance characteristics. However, not every feature of a specification needs to correspond directly to a software component.

Option 2 has the following advantages over option 1:

• Its definition is quite unlike that of a selector, so there is likely to be less confusion between the terms *picker and selector.
• The picker interface is narrower than in option 1 because the parent node is not passed to the picker and the *picker does not determine the order of the selector's nodelist.

An alternative approach avoids the need to give pickers semantics in isolation from the child selector. This is a kind of axiomatic semantics which describes the semantics of the variants of `[picker](with a single *picker) and then defines the semantics of[pickers]` (with two or more pickers) in terms of the semantics of [*picker]. (This is similar to the way the current draft builds the semantics for the list selector in terms of the semantics of other selectors.)

[glyn]

This was discussed thoroughly at the 2022-9-27 interim meeting. @goessner was uncomfortable with option 1 and preferred option 2. @glyn warmed up to option 1 during the meeting. We decided to proceed with option 1 (as per PR #258) and see how clear we can make the resultant spec.

[glyn]

I think option 1 is panning out ok. Closing, for now.