W3C

- DRAFT -

XForms Users Community Group Teleconference

17 May 2017

Agenda

See also: IRC log

Attendees

Present
Alain, Erik, Steven
Regrets
Philip
Chair
Steven
Scribe
Steven

Contents


ACTION-2121 - Reformulate text for @incremental

https://lists.w3.org/Archives/Public/public-xformsusers/2017May/0018

Steven: [Describes the reasoning behind the new text]
... [as in the email]

Erik: I am OK with this

Alain: I haven't had a chance to read it yet.

Steven: Why not read it now.

Alain: OK
... I'm almost OK with this
... No, I'm OK with it.

Steven: OK, I'll make the change.

<scribe> ACTION: Steven to update the spec @incremental text [recorded in http://www.w3.org/2017/05/17-forms-minutes.html#action01]

<trackbot> Created ACTION-2122 - Update the spec @incremental text [on Steven Pemberton - due 2017-05-24].

Alain: I have a @delay for dispatching events on @incremental

Steven: It's not in the spec

Erik: Maybe we talked about it in the past

Event marking and dispatch

https://lists.w3.org/Archives/Public/public-xformsusers/2017May/0014

Steven: I had completely forgotten about that link you posted

https://www.w3.org/MarkUp/Forms/wiki/Improved_UI_Events

Erik: This description is much more high level than before, which is good
... I think we can make it even more simpler

Steven: That sounds good

Erik: I am happy that the marking is gone. I never did like that.

Steven: You are saying that a control only needs a value-changed event only if the value changes

Erik: Exactly, and the other MIP events

- When a control becomes non-relevant, we might want to avoid dispatching

other MIP events and value changes.

- When a control becomes relevant, we have to decide whether we want to

dispatch any MIP/value events.

Erik: I would be OK with that not being fully described.
... what to do when controls get created - do they get events?

Steven: On UI initialization controls don't get events; I would expect the same for when a control is created. I don't mind which way, as long as they are consitent

Erik: One option would be when a control becomes relevant (from the relevant event) that the event context contains the MIP information.
... Going back to your question, I think it is easy to specify.
... and the spec would become simpler.

Steven: I'll give it a try

<scribe> ACTION: Steven to update the control events as per the email. [recorded in http://www.w3.org/2017/05/17-forms-minutes.html#action02]

<trackbot> Created ACTION-2123 - Update the control events as per the email. [on Steven Pemberton - due 2017-05-24].

ACTION-2120: Research the relationship between the recalculate

(etc) events and the actions

https://lists.w3.org/Archives/Public/public-xformsusers/2017May/0015

Steven: So are these events redundant?

Erik: I don't think we need them
... if we have them, it should be informational
... and the split between recalculate and revalidate is problematic

Steven: I agree.

Alain: There might be users with special JS libraries that use them, so they *might* be useful.

https://www.w3.org/community/xformsusers/wiki/XForms_2.0#Events

Steven: I showed events that correspond with actions in that table

Erik: There's also the other way round, some actions have no corresponding event, like setindex
... I don't see as point of the events having an effect as well as the action.
... I don't mind having the event as well though.
... I can imagine having a notification event for update-done, and refresh-done
... as being useful.

Steven: So do we leave the events as historical?

Erik: Deprecate

Alain: That's OK with me.

<scribe> ACTION: Steven to deprecate the refresh etc events [recorded in http://www.w3.org/2017/05/17-forms-minutes.html#action03]

<trackbot> Created ACTION-2124 - Deprecate the refresh etc events [on Steven Pemberton - due 2017-05-24].

Default for dispatch/@targetid

https://lists.w3.org/Archives/Public/public-xformsusers/2017May/0009

Steven: Not an important point, but it struck me that there was a dissimilarity between handler and dispatcher

Erik: We do have special id style in our implementation
... occasionally useful.

Steven: Anyway, I propose leaving this now.

Erik: Sure

Validation and optional fields

https://lists.w3.org/Archives/Public/public-xformsusers/2017May/0003

Steven: I intended to spend more time on this this week, and didn't.
... so I'll put this item off to next week.

AOB

[None]

[ADJOURN]

Summary of Action Items

[NEW] ACTION: Steven to deprecate the refresh etc events [recorded in http://www.w3.org/2017/05/17-forms-minutes.html#action03]
[NEW] ACTION: Steven to update the control events as per the email. [recorded in http://www.w3.org/2017/05/17-forms-minutes.html#action02]
[NEW] ACTION: Steven to update the spec @incremental text [recorded in http://www.w3.org/2017/05/17-forms-minutes.html#action01]
 

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/05/17 13:40:56 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/iton/tion/
Succeeded: s/struct/struck/
Succeeded: s/ponly/only/
Present: Alain Erik Steven
Regrets: Philip
No ScribeNick specified.  Guessing ScribeNick: Steven
Inferring Scribes: Steven
Agenda: https://lists.w3.org/Archives/Public/public-xformsusers/2017May/0019
Found Date: 17 May 2017
Guessing minutes URL: http://www.w3.org/2017/05/17-forms-minutes.html
People with action items: steven

[End of scribe.perl diagnostic output]