Markup UK

http://markupuk.org/index.xhtml

Steven: This weekend.
... I'm talking on the XForms testsuite

Embedded XForms

https://lists.w3.org/Archives/Public/public-xformsusers/2018May/0033

Steven: Are we in a ready state to discuss?
... It seems to solve many of the problems; no clashing IDs, uses existing mechanisms. Solves my use cases in any case! :-)

Erik: If I userstand, the subform can communicate using submission, and it can do it multiple times.

Steven: Here is the correct link: https://lists.w3.org/Archives/Public/public-xformsusers/2018Jun/0000.html

Erik: Can the enclosing form communicate multiple times?

Steven: Yes, [There is an action <renew control="id"/> that causes the initial values

reference to be copied to the embedded instance again]

Erik: So there is complete isolation between the two.
... How about passing events?
... In browsers, webworkers live in isolated memory space, you can pass information back and forth using buffers of data
... the logic is that data is always copied

Steven: Similar to this proposal

Erik: How about dispatching events?
... Would be tricky
... Embedded form could announce readiness to do stuff at any time.

Steven: We could expand <dispatch/> to send events into an embedded form or out of an embedded form.
... that would make embedded controls act like existing native controls.

Erik: Where would events be dispatched to?

Steven: for the parent it would be the <control/> element itself
... but for the embedded form, the <model/> seems like a consistent place; we send events to the model when there is no other obvious place (eg xforms-ready)

Erik: First model?

Steven: Or all, as happens with xforms-ready; we would have to decide.
... Sounds like a good addition. We ned to think about if it requires a change to <dispatch/> to send an event into an embedded form.
... I'll work on it further, and make those additions, and we can talk about it again.

Submission echo

https://lists.w3.org/Archives/Public/public-xformsusers/2018May/0037

Steven: Since the embedded controls use a new sort of method in submission, that could solve our echo submission issue.
... using a method="xforms-echo"

Erik: I'm not a fan of using @method.
... it includes http method, and other stuff too.
... it feels like reusing that attribute for other things.
... not because it is fundamentally a 'method'.

Steven: Not sure if I agree. It's not a 'scheme' either.

Erik: Not sure what to think about it.
... for method at present we have get, post, delete, put, multipart-post, etc.

s/-put/-post/

Erik: Taking multipart-post, it packages several things into one token...
... not very clean
... there should be a separate way of specifying "multipart" (not part of this topic though)

Steven: I hear you're not very happy about it; let's think on it more.

Test Suite 2.0

https://lists.w3.org/Archives/Public/public-xformsusers/2018Apr/0051

Steven: No news.

AOB

Steven: Next week I'll ask about planned vacations.

[ADJOURNED]

<scribe> ACTION: Steven to incorporate events into embedded forms proposal

<trackbot> Created ACTION-2186 - Incorporate events into embedded forms proposal [on Steven Pemberton - due 2018-06-13].

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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/
Succeeded: s/multi-/multi/
FAILED: s/-put/-post/
Succeeded: s/sontrols/controls/
Succeeded: s/consisten/consistent/
Succeeded: s/multi-part/multipart/
Present: Alain Erik Philip Steven
No ScribeNick specified.  Guessing ScribeNick: Steven
Inferring Scribes: Steven
Agenda: https://lists.w3.org/Archives/Public/public-xformsusers/2018Jun/0003
Found Date: 06 Jun 2018
People with action items: steven

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.)