Meeting minutes
https://
https://
ACTION-2309: Research xpath3 function definitions (Erik)
Steven: Not this week though
ACTION-2312: Devise text for submission using @value (Steven)
https://
https://
Steven: https://
Alain: Use the same solution we use for output.
Erik: We do something different - we say that ref acts as a binding, supplying a context for @value
… in XF 1.1 we say ...
<ebruchez> XForms 1.1: "value Author-optional. An XPath expression to be evaluated. The string result of the evaluation is rendered by the form control. If binding attributes are present to select a node, this attribute has no effect."
Steven: For output we say "The data to be rendered is obtained by evaluating the value attribute if present, or otherwise from the Single Item Binding if present, and otherwise from the inline data."
Erik: That would simplify submission; if value is present, you use it, otherwise the binding
Steven: Look at https://
… so @ref gives the element evaluation context, and as far as I remember other attributes are evaluated in that.
… "Unless otherwise stated, all expressions (including those in AVTs) in an element are evaluated in the element evaluation context"
Steven: That answers q1
… then I proposed: @value: a value that is converted to a string
@ref, @bind, @relevant, @nonrelevant, @validate: not used.
@serialization: not used
@mediatype: used.
Alain: We could use @ref for the context
Steven: You are right
… for the context
Steven: The last question whether it adds any functionality. But it adds consistency.
Alain: It makes a big difference for me.
ACTION-2313: Research the alternatives for 'dirty' data, and produce
code in all of them for comparison
https://
https://
Steven: That's a draft article, not yet published, but deals with the topic.
Alain: The engine doesn't know if it is dirty or not.
… So you can't report that the page is dirty.
Alain: It's not an XForms mechanism.
… It doesn't have to be an automatic mechanism, just some way to do it.
Erik: Either an event or an action
… tell the system that we have or no longer have dirty data
Timescale Plans
https://
In particular today, focusing on <control/> and instance mirroring:
User-defined controls (with instance mirroring)
Steven: The current mechanism copies data in, and out again at specified moments.
… We said it would be good if it worked like native controls, just mirroring the instance.
… The question is how to specify how that should happen.
… We have an XForms that could work by itself, but if you embed it, you want to communicate between the embedder and the emnedded.
Erik: We do the mirroring already.
… it works by synchronisation
… and it works synchronously as well
… it works for all nodes, adding nodes, or attributes, etc.
… you get the same XML on both sides
… namespaces may be tricky
… The caller elements may have ancestors, but the embedded version may not, probably doesn't.
Steven: On initialisation, does the subtree get copied across?
Erik: Yes.
Steven: And the MIPS of the caller?
Erik: We don't copy those properties, there may be conflicts
Steven: When copied, do they replace the leading instance?
Erik: We use an attribute to say that the instance is mirrored.
Steven: So the presence of that attribute says that that one is where the copied data goes.
… and is therefore mirrored.
Steven: And so a mirrored instance knows that data has to be synchronised.
Erik: The mirroring works in both directions.
Steven: Sounds wonderful.
Erik: One limitation is that if the embedded form says something is invalid, the caller doesn't know that.
… we use events to communicate
… the outer form can dispatch events to the outside of the embedded form
… and vice versa, we can dispatch an event from the inside to the outside.
… if you dispatch an event to the control element, it is normal handling. If the embedded form doesn't have a handler for it, nothing happens.
<ebruchez> <handlers>
Erik: there is a special section for handling incoming events coming in, in the embedded form
… it's not the root element of the embedded form. It is something outside.
… you could say that any event that is dispatched, you could listen for it on the root element.
… using the target attribute, you could make sure you were catching ones specifically dispatched to that element.
Steven: Next question is, how to specify that an event is being dispatched to the embedding?
Erik: We have another element.
Steven: We have <signal/> at the moment.
… seems cleaner than having a special element
Erik: We have special names.
Steven: We could say that leaving @target off <dispatch /> it goes to the embedder.
Steven: We have solved everything except where the incoming events go to
Alain: So add a listener to <html/> element
Steven: Yes.
ACTION: Steven compose text that matches the <control/> discussion for mirrroring.
<trackbot> Created ACTION-2314 - Compose text that matches the <control/> discussion for mirrroring. [on Steven Pemberton - due 2022-02-04].
Erik: We might find some inpsiration from web components. We should look how they use events.
ACTION: Erik to report on event handling in web components.
<trackbot> Created ACTION-2315 - Report on event handling in web components. [on Erik Bruchez - due 2022-02-04].
AOB
[None]
[ADJOURN]