Meeting minutes
ACTION-2314: Compose text that matches the <control/> discussion for
mirroring (Steven)
https://
Steven: Not sure where Alain is. I'll send him a message.
https://
https://
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)