ACTION-2327 - Write an email proposing a method for events

All,

Terminology:

- embeddING form: form with the `<control>` element
- embeddED form: form/component which is embedded by the embedding form

As a reminder, we'd like to have two-way event-based communication between
the embedding and the embedded form.

Doing so is straightforward with the architecture proposed by Web
Components, as I showed a few weeks ago with my simple prototype
in JavaScript. [1] All you need in that case is:

1. Embedding form
  1.1. ability to dispatch an event to the element representing the
component (or form)
  1.2. ability to listen to an event dispatched to the element
representing the component (or form)
2. Embedded form (here a Web Component)
  2.1. ability to dispatch an event to the element representing the
component (or form)
  2.2. ability to listen to an event dispatched to the element
representing the component (or form)

This to me makes sense from an architectural/requirements perspective, and
independently from a particular implementation. It is also good to map to
what Web Components do. Finally, this doesn't require using a shadow DOM or
an actual Web Components implementations and could, for example, go through
an iframe boundary.

In XForms we typically use:

1. For sending events: the `<dispatch>` action
2. For listening to events and running actions in response: declarative
event handlers attached to observers with the `ev:observer` attribute or
direct element nesting (which observers the parent element).

(These provide exactly the same capabilities that JavaScript has with
`dispatchEvent()` and `addEventListener()`.)

I think we can do everything with these two mechanisms provided we add a
couple of capabilities:

1. The ability, in the embedded form, to dispatch an event that reaches the
embedding form's `<control>` element if present.
2. The ability, in the embedded form, to listen to events targetting or
passing through the embedding form's `<control>` element if present.

(From the point of view of the embedding form, nothing is changed: you
dispatch events and listen to events in the usual way.)

With JavaScript and Web Components, you can easily do this programmatically
[1] because you have a reference to the equivalent of the `<control>`
element (which is an HTML custom element in that case). So it's just a
matter of calling `dispatchEvent()` and `addEventListener()` and knowing
what you are doing.

In XForms, we don't have at this point such a reference: we work with more
declarative constructs, via element nesting, `id` references, and other
configurations via attributes. However, we could add such capabilities.

In the Orbeon implementation, because we used XBL as inspiration, we chose
the following solutions:

1. Dispatching events to the `id` of the `<xbl:binding>` element.
2. Listening to events using `observer="id-of-the-binding".

(I am not suggesting such a solution right now for XForms, although we
could consider it.)

However, in XForms, right now we don't have such an `id`. And if we use the
`id` of the proposed `<interface>` element, we have the problem which we
discussed previously, namely that that element would then behave
differently from other elements with regard to event capture/bubbling. You
would have two solutions:

1. Retarget/duplicate the event so that it reaches `<interface>` and then
captures/bubbles inside the embedded form.
2. Not let the event capture/bubble inside the embedded form.

I think these two solutions, while not terrible, are not optimal.

Instead, since what we (or at least I) would like to do is in the end just
provide the requirements I describe above, we could instead extend
`<dispatch>` and event handlers. Here are a couple of proposals:

Proposal 1: use a special attribute value to indicate the embedding form's
`<control>` element. For example, in the embedded form:

    <dispatch name="my-event" targetid="#embedding-element"/>

And:

    <action ev:observer="#embedding-element"/>

This echoes the use, in XSLT, of the symbol "#" for special modes. But we
might be able to find another symbol.

Proposal 2: use new attributes. For example:

    <dispatch name="my-event" target-embedding-element="true"/>

And:

    <action ev:observe-embedding-element="true"/>

(The attribute names are just placeholders.)

Solutions along these lines would:

- satisfy the two-way communication requirement
- be conceptually compatible with Web Components
- while not requiring an actual Web Components implementation
- not require any special event handling capabilities from the embedding
form
- not add new actions

-Erik

[1]
https://lists.w3.org/Archives/Public/public-xformsusers/2022Oct/0001.html