[Last meeting this month; next meeting Jan 8]
https://lists.w3.org/Archives/Public/public-xformsusers/2020Dec/0007
Steven: Can you use @instance and @targetref at the same time?
Erik: I think so.
... Let me check.
... I need more time to check.
... I think it's the case. The spec might say something.
Steven: replace="instance"
instance="foo" targetref="instance('bar')"
... what should happen in that case?
Erik: I was thinking one is relative to the other. Then instance="" sets the context, and then targetref is releative to that, and that answers the question
Steven: Good answer
Alain: I agree
<scribe> ACTION: Steven to check that spec for @instance and @targetref is fully defined
<trackbot> Created ACTION-2293 - Check that spec for @instance and @targetref is fully defined [on Steven Pemberton - due 2020-12-25].
Erik: I will double check that that is what we do.
https://lists.w3.org/Archives/Public/public-xformsusers/2020Dec/0008
Alain: What about <header> elements?
Erik: I think it would be good to allow <send> to have them as well.
Steven: Good.
Erik: I'm not happy with the
events going to the send element though.
... do we have a precedent for an action getting events?
Steven: Yes <load> gets load-error events.
Erik: There is the question of
sequencing submissions.
... if they are synchronous, then the first would run, blocking
other things, and then the second would run regardless.
... if they are asynch (the default now), the first would
start, and I think the second would start, not sequnced.
Steven: I do <submission....><send ev:event="xforms-submit-done".../></submission>
Erik: It's not convenient in general.
Steven: I'm happy to try and find a better solution, let's think about it.
Erik: If we had a better way, it would matter less where the event was sent.
Steven: Do we care about <load
ref=""/>?
... it is just the same as resource="{...}"
... load has @ref and @resource
Erik: I think it can stay.
Alain: It's not consistent.
... avt on resource makes it useless.
Steven: We could deprecate it.
Erik: I could live with that.
RESOLUTION: deprecate load/@ref
Steven: What should happen if load transmission fails? We don't say.
Erik: It should be the same as with suibmission ideally.
Steven: Do we want load to also have all the submission attributes
Erik: Keep it simple.
Steven: http://invisiblexml.org
... created yesterday FYI.
... there is a unofficial WG working on implementations, the
spec, and test sets.
[ADJOURN]
<scribe> ACTION: Steven to spec load URL traversal failure
<trackbot> Created ACTION-2294 - Spec load url traversal failure [on Steven Pemberton - due 2020-12-25].
This is scribe.perl Revision of Date 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/time./time?/ Succeeded: s/deprectae/deprecate/ Succeeded: s/eb/be/ Succeeded: s/I'm to try/I'm happy to try/ Succeeded: s/RESOLUTION/RESOLUTION:/ Present: Alain Erik Steven No ScribeNick specified. Guessing ScribeNick: Steven Inferring Scribes: Steven Agenda: https://lists.w3.org/Archives/Public/public-xformsusers/2020Dec/0009 Found Date: 18 Dec 2020 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.)[End of scribe.perl diagnostic output]