XForms Users Community Group Teleconference

11 November 2022


Alain, Erik, Steven

Meeting minutes

ACTION-2314: Compose text that matches the <control/> discussion for

mirroring (Steven)


Steven: Not sure where Alain is. I'll send him a message.



Steven: Have a look at that, which records the requirements and decisions we have made to date, and puts questions that need an answer.
… There's one other question that has arisen for me since then: is the mirroring bi-directional?

Steven: Q1 Shape of the data. Are there restrictions, or is the ref just copied in?

Erik: We don't do anything special. The only restriction is that the control binds to an element, which becomes the root element of the mirroring.

Steven: Is the receiver just an instance?

Erik: Yes, it has to be an instance (in our implementation). Technically you could, like @targetref in submission
… we didn't have a need for a sub-instance

Steven: So this suggests that the <instance/> element should have an @instance element, rather than a @ref.

Alain: Why not an attribute, for instance for a colour picker control.

Erik: We would need to decide how the mirroring would work. A root element on an instance is easier to handle.
… you do in general bind to an attribute or element in XForms.
… From the embedded form, you are going to change the text node, so if you are controlling the vlaue, how does the embedded for know what you are bound to?
… For attributes I'm not sure how to do it, though it would be good to be able to do that.

Steven: If we did allow attributes, would it be allowable to bind an attribute on one side to an element on the other?

Erik: Yes, as long as the embedded form doesn't have children.

Steven: So the answer to Q1 is yes.

Erik: There are binding restrictions in the spec. You can't bind an <input/> to an element with children.

Steven: That uses special knowledge about the elements. We would need to be able to specify that.

Steven: Q2: Does the mirroring work in both directions?

Erik: We do both.
… there is a trick: which direction initially.
… EG If the embedding is responsible for saving the data.
… The subform supplies the data
… the embedder doesn't have any initial values.
… Case 2, the outer form does have initial values.

Erik: There needs to be a way to specify.
… The logic we use is if the embedded form is bound to an an element, and the element contains *any* content* that is used as the initial values. If it *is* empty, it gets the values from the embedder.

Steven: Q3 Do events perform any differently in either forms?

Erik: It's not only bubbling.
… but I'm not sure how it work.
… we can explore that.
… I want to avoid duplicating events.

Alain: How it is implemented should be independent of the notation
… we should have events as specced.

Erik: I'm not requiring web components, just bearing in mind how they are done there.

Alain: If the embedded form is just a subtree, it should continue to work the same.

Erik: If you embed a form does the embedding form get new stuff; are all the embedded forms events bubbling out?
… I think it would be better if they didn't.

Steven: Q4 What are the ramifications for xforms-ready.

Alain: We have subform-ready event in XSLT Forms

Declarative Amsterdam

Steven: It went well. I talked at length with the person from Fore, who are the people from Betterforms. We talked about possibilities of converging.
… Good turnout, about 75 attendees, from all over the world, even in person. Next year is 2/3 Nov (Thurs/Friday)

Minutes manually created (not a transcript), formatted by scribe.perl version 196 (Thu Oct 27 17:06:44 2022 UTC).


Succeeded: s/;/'/

Succeeded: s/;/:/

Succeeded: s/DO/Do/

Succeeded: s/ebedder/embedder/

Succeeded: s/nirroring/mirroring

Succeeded: s/convergind/converging

No scribenick or scribe found. Guessed: Steven

All speakers: Alain, Erik, Steven

Active on IRC: Steven