Meeting minutes
ACTION-2325: Steven and Erik, check the new submit-ready text
https://
Erik: Continues
ACTION-2314: Compose text that matches the <control/> discussion for
mirroring (Steven)
https://
"Either side can bind to an attribute
(https: //www.w3.org/2022/11/11-forms-minutes#t01),
but in that case both have to bind to a text node,
and the embedded form's referenced item must not have children.
QUESTION: And vice versa?"
Alain: I would think so.
Steven: I agree, but I wanted to check we all had the same agreement.
"QUESTION: How do we determine if the embedded form gets initialised from
the referenced data
or from its own data? Use heuristics, or should the <interface/> element "
specify that?
Steven: I think there is a good reason for the <interface/> element to specify which direction the initialisation comes from (the current proposal in the spec specifies it from the <control/> element)
Erik: Probably better to be explicit.
… in our implementation, mirroring only happens for complex content.
… we can also specify that a binding works like <input/>
Steven: From what you just described it sounds like there are three values for where initialisation comes from: external, internal, none.
Erik: I think it should be a dynamic, not static.
Steven: Use case?
Erik: Sub-form where the embedded form submits/stores the data; in some cases the outer form already has data, in other cases not.
… it also depends on when the embedded form gets initialised in the life-cycle
… sub-forms get initialised during the first refresh.
… seems to make sense.
… that's why we need heuristics.
… to prevent overwriting data.
Steven: That seems then still to need thought about how we specify initialisation....
… but that does answer the question about XForms-ready. which happens after the initial refresh.
Erik: The alternative would be to defer xforms-ready until after the sub-forms are ready
Alain: We have a different event for sub-forms, because we use <load/> to load sub-forms.
Steven: I have a similar use case with the XForms test suite, where I load a subform with an iframe with an attribute value
Alain: Can you communicate with an iframe.
Steven: I don't know yet. Possibly.
Alain: It's the way to specify an app with a single page
… is iframe deprecated?
Steven: Oh! Hadn't heard.
ACTION: Steven to find out if iframe is deprecated.
<trackbot> Created ACTION-2326 - Find out if iframe is deprecated. [on Steven Pemberton - due 2022-12-09].
"Question: If there is a binding mismatch, an xforms-bind-error is dispatched.
QUESTION: On the embedder side?"
Alain: the parent form
Steven: That was my feeling too.
<ebruchez> https://
Erik: Makes sense.
"QUESTION: Which is better?
1. Events targeted to <control/> and <interface/> perform the same,
and so bubble up from the <control/> or <interface/> in the dispatching
form,
therefore appearing in both forms.
2. The <interface/> and <control/> elements have magic so that if they are
targeted,
the events neither bubble nor capture on the dispatching side.
3. We introduce a new action, say <signal/> with comparable attributes to
<dispatch/>
which causes a <dispatch/> to happen on the other side of the
interface,
so that the event only appears in the form being signalled to.
4. Something else?"
Steven: I think we agreed that 1. is not desirable.
… my gut feeling is that 3. is preferable.
Erik: I don't like 3.
… there are two sides. From the embedded form I have less of a problem. It is clear you want to dispatch an event to the outside.
Steven: I'm trying to find a way to specify it that would allow different implementations.
[Long discussion of implementation techniques, where the scribe was deeply involved]
Alain: We could use the <form/> element we already have.
Erik: I will write an email with some examples
ACTION: Erik to write an email proposing a method for events
<trackbot> Created ACTION-2327 - Write an email proposing a method for events [on Erik Bruchez - due 2022-12-09].
ACTION: Alain to write an email froposing the use of <form/>
<trackbot> Created ACTION-2328 - Write an email proposing the use of <form/> [on Alain Couthures - due 2022-12-09].
[ADJOURN]