Profile resolution: clarify requirements for identifying 'add' positions

[wendellpiez]

This issue was surfaced by #1305.

Describe the bug

The current profile resolution specification in the Modify phase needs some clarification regarding handling of ID bindings on add and remove - the section is "Modify Phase / Adding contents to controls / Explicit binding". There is some inconsistency in that actual problems, such as targets that do not resolve, are ignored, while less severe lapses, such as a add/@by-id targeting the same control as the alter statement it appears in (which is redundant but not ambiguous), are specified as errors.

We see three (no, four!) potential strategies for dealing with explicit bindings of add (or remove) directives to controls:

Draconian - any by-id that does not identify a legitimate target throws an error. This includes by-id identifying the control itself. A legitimate target would be any descendant that is not also a descendant of a descendant control.

Strict - like Draconian, except add/by-id targeting the control (i.e. same as the parent alter) is permitted as a variant of no by-id (implicit binding to the control). Like that variant, positions "before" and "after" would be taken as synonyms of 'starting' and 'ending' respectively.

Sort of permissive (the current spec) - add/by-id that does not correspond to a legitimate target is non-operative (silent, no error) unless it identifies the control itself, in which case it is an error.

Permissive - add/by-id indicating the control is not an error, but is treated like add[empty[@by-id)] i.e. an implicit binding to the control. A processor could have an option of emitting a warning indicating that a target is missing.

A fifth option - permissive but making the explicit binding to the control a no-op -- doesn't seem to make much sense.

NB - alter/remove may also need examination for these issues.

Who is the bug affecting?

Profile resolution implementers; developers and users of profiles.

What is affected by this bug?

This is a minor issue but may be important in certain edge cases.

Expected behavior (i.e. solution)

Clarify the Profile Resolution Specification.

Revisit the implementation accordingly.

[david-waltermire]

@wendellpiez My leaning is towards using the "strict" option, which will allow by-id to duplicate the identifier of the target of the alter. This will not invalidate existing profiles that do this and will reduce noisy errors caused by taking the "draconian" approach. This seems like a good balance.

[aj-stein-nist]

Dave has rolled of the project, so AJ will pick this up and work with Wendell to cover this in the next sprint.