Steven: This week was the 30th anniversary of internet in Europe so it's been a busy week for me.

ACTION-2207: Merge <signal/> into <dispatch/>

https://lists.w3.org/Archives/Public/public-xformsusers/2018Nov/0008

Steven: Thanks for your reply.

Erik: The reason I don't like @to
... is that it is generic.
... also @targetid is also a sort of 'to'

s//

Erik: @to is not clear what it means, and I was looking for a 'standard' way
... I don't disagree about booleans, but we do have other booleans.
... The name they chose is indeed a strange choice.
... No idea why it is 'composed'.
... So I liked using the same thing, because it does what we want to do

Steven: In one direction.

Erik: Yes.
... It is similar to the Shadow DOM
... In the other direction, I couldn't find anyone even broaching the topic.
... in our implementation we used ideas from the now obsolete XBL spec
... the idea (that I didn't explain), if you want to pass an event from the outside to the inside
... the idea is that in the parent form, you dispatch to the embedded form
... the embedded form has a special handler
... in our implementation we use special syntax

Steven: I honestly don't understand

Erik: The current text says the event goes to the first model of the embedded form.

Steven: I chose that because it's the first element that we have control over, since we don't have a root element.

Erik: We could still say "the root element"

Steven: We still don't necessary have the possibility of putting an action handler under the root. It may not even have an id.

Erik: Another disadvantage of the current version (not necessarily a big problem)
... anyone can dispatch any old event to the embedded form, even xforms-submit-done or whatever
... so submission of arbitrary events to particular elements can cause a problem.
... so the embedded control needs more control over incoming events.

Steven: OK, thanks for the input. I'll think more on it.

Erik: Here is the reference

<ebruchez> XBL 2 spec for handlers https://www.w3.org/TR/2007/CR-xbl-20070316/#the-handlers

Erik: A lot of thinking has been done in the past, so we should try and map to the existing ideas.

Tree traversal

https://lists.w3.org/Archives/Public/public-xformsusers/2018Nov/0006

Erik: No time to think about it this week.

ACTION-2206: Propose text for using mirroring for <control/>

https://lists.w3.org/Archives/Public/public-xformsusers/2018Nov/0010

Steven: https://lists.w3.org/Archives/Public/public-xformsusers/2018Nov/0018.html
... I really like mirroring
... but I do miss the use case of being able to send a nodeset
... rather than just a single element.

Alain: I was thinking about distinguishing between output and input controls.

Steven: I agree.

Alain: a readonly control

Erik: There is clearly a need to send parameters.
... We had a problem with this with the components in our implementation
... it is fair to say it is good to have
... In your case the main problem is the filtering

Steven: Yes, any time you want to calculate an expression.

AOB

Steven: I haven't had time for any of the other agenda items this week.

[ADJOURN]

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/TH/Th/
WARNING: Bad s/// command: s//
Succeeded: s/TH/Th/
Succeeded: s/directions/direction/
Succeeded: s/inside to the outside/outside to the inside/
Succeeded: s/TH/Th/
Succeeded: s/yt/t/
Succeeded: s/Topic AOB/Topic: AOB/
Succeeded: s/THanks/Thanks/
Succeeded: s/paramaters/parameters/
Present: Alain Erik Philip Steven
No ScribeNick specified.  Guessing ScribeNick: Steven
Inferring Scribes: Steven
Agenda: https://lists.w3.org/Archives/Public/public-xformsusers/2018Nov/0015
Found Date: 21 Nov 2018
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)