14:00:25 RRSAgent has joined #forms 14:00:25 logging to http://www.w3.org/2009/06/18-forms-irc 14:00:30 zakim, this will be forms 14:00:30 ok, John_Boyer, I see Team_(forms)13:58Z already started 14:01:29 rrsagent, make log public 14:01:37 zakim, code? 14:01:41 the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), John_Boyer 14:02:01 +John_Boyer 14:02:10 zakim, who is here? 14:02:10 On the phone I see wiecha, John_Boyer 14:02:12 On IRC I see RRSAgent, John_Boyer, Zakim, wiecha, klotz, nick, Steven, trackbot 14:02:55 +[IPcaller] 14:03:21 zakim, I am [IPcaller] 14:03:23 ok, nick, I now associate you with [IPcaller] 14:04:19 +Leigh_Klotz 14:04:30 unl has joined #forms 14:04:46 kenneth has joined #forms 14:04:57 Meeting: W3C Forms Working Group Virtual Face to Face Meeting, June 18, 2009 14:05:02 Agenda: http://www.w3.org/MarkUp/Forms/wiki/vFtF_2009_06_18 14:05:05 zakim, dial steven-617 14:05:06 ok, Steven; the call is being made 14:05:07 +Steven 14:05:14 John_Boyer has changed the topic to: Code is CONF1 (26631); http://www.w3.org/MarkUp/Forms/wiki/vFtF_2009_06_18 14:05:16 +unl 14:05:25 +kenneth 14:05:29 Chair: John 14:06:22 Scribe: Charlie 14:06:31 scribenick: wiecha 14:07:09 John: emails went out with agendas for upcoming couple weeks...pls comment 14:07:27 I took the liberty to write something up for the Case Function 14:07:27 Topic: Data-driven Switch and case() function 14:07:41 John: both have interest and/or implementations 14:07:55 "The forms you use in a US post office are produced with XSL-FO and XForms; your bank statement may have been produced with XSL-FO." 14:08:01 ...on data-driven switch, we've talked about this in the past and there's a recent email thread with some new ideas 14:08:04 Just saw this today 14:08:40 John: previously we talked about an element child of switch, with SNB, called it "using" for lack of better name at the time 14:08:59 ...also talked about another attribute on switch element, with xpath value 14:09:26 ...only downside to using attribute is by comparison with element don't have opportunity to use @bind for IDREF for xpath 14:09:39 ...with child element have full set of binding attributes available 14:09:40 MarkB propose: 14:09:46 ... ... ... ... 14:10:30 John: I pointed out on the list that @value doesn't create two-way binding (full SNB behavior) 14:10:53 ...data-driven behavior goes in both directions -- i.e. switching case using toggle drives data back into instance as well 14:11:14 Nick: i like option of using @value if you want only 1-way binding 14:11:16 ... ... ... ... 14:11:41 Leigh: what does it mean to use selected value? could be conflicts between toggle action and data binding values 14:11:54 John: yup, toggle might have to be no-op in that case 14:12:05 Leigh: also what if selected node is read-only? 14:12:17 John: yup, that's a comment about use of SNB 14:12:39 ...I have an impl with foreign-namespaced attribute where we handle these cases 14:12:56 ...if you try to toggle case and it has this binding, looks at node, if read-only, toggle no-ops 14:13:07 Leigh: but no way for trigger issuing toggle to know 14:13:17 ...i.e. no way to give feedback to user 14:13:29 Nick: some impls can tell if binding is read-only 14:13:32 John: it's computable 14:13:39 Charlie: but inconvenient 14:14:47 John: also can use setvalue instead of toggle, goes to readonly node, may fail...same issue 14:14:53 s/may/will 14:15:16 John: topic on agenda for two weeks from now to talk about extending xforms to allow authors to query MIPs using xpath 14:15:21 ...would help here 14:15:29 Leigh: yes, but would be nice to do declaratively 14:15:38 ...what about trigger and R/O refs? 14:15:51 Nick: unavailable then 14:16:09 Leigh: then could bind trigger to R/O node 14:16:25 davidlandwehr has joined #forms 14:16:29 ...same node as switch is looking at 14:16:46 John: oops, we went other way in trigger behavior 14:17:07 http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#ui-trigger 14:17:25 ...R/O MIP does not affect whether trigger can be activated 14:17:31 ...would need @if... 14:17:57 14:18:17 Charlie: but this sounds like what the author would want as default 14:18:38 separate discussion about function for model-property because it might be hard to get dependencies for such a function 14:19:49 Hmmm, we make the tiger disappear when not relevant, and read-only when the the node is read-only.... 14:20:07 s/tiger/trigger/ 14:20:18 John: if instead of SNB we used @value this could work as long as toggle as no affect on switch if the switch was using @value 14:20:37 s/toggle as/toggle has 14:20:56 John: should we back up to R/O trigger behavior? 14:21:26 Leigh: April 29th, 2007 14:21:28 http://lists.w3.org/Archives/Public/public-forms/2007Apr/0046.html 14:23:26 http://lists.w3.org/Archives/Member/w3c-forms/2007JanMar/att-0219/20070321-3.html#ACTION3 14:23:28 John: seems like disabling trigger when R/O is the preferred behavior 14:23:37 ...back to data-driven switch... 14:23:58 ...what if author does setvalue to node with value that fails to match any case in the switch? 14:24:05 Leigh: switch is out-of-range 14:24:13 John: yes, but which case should be selected 14:24:37 ...in our case (sorry) we said that was ok, and we'd fall back to the default specified on the case elements 14:24:51 ...want the behavior to be reliable 14:25:05 What happens if we toggle a non existant id value? 14:25:15 s/tant/tent/ 14:25:49 ...e.g. if save the data and reload into fresh form template...not reasonable to say if you change the value of the node to non-matching node the switch should just stay "where it was"...that's not preserved across save and reload 14:26:11 Leigh: might not be a @default...so perhaps none of them should display 14:26:14 Steven: +1 14:26:23 John: acceptable to me...it's stable across save/reload 14:26:41 Leigh: need to decide if you have both instance value and @default 14:26:59 John: data-driven version should override...same as behavior of switch now...runtime toggles change cases 14:27:29 Leigh: if you start with instance of empty string and valid @default...or non-matching instance but still have @default... 14:27:39 John: right, but never let default drive the data 14:27:54 ...by virtue of opening the document the data should not change...that's broken 14:28:04 ...unless there's an explicit action handler 14:28:13 s/handler// 14:28:31 Leigh: when would the @default be used? 14:28:36 John: when data is out of range 14:29:27 ...selected construct binding to data override @selected on cases 14:30:25 Leigh: getting close to the behavior for select/select1 14:30:57 ...could do the same thing for out-of-range for switch/case 14:32:42 Nick: might be confusing to have the switch be completely gone if out of range 14:33:23 John: if instance starts out empty...driving the switch w/o data is not a good idea... 14:33:57 ...so first question is: do we want @value or SNB approach? 14:34:02 Charlie: SNB 14:34:06 Leigh: binding 14:34:31 John: comes with a few more "qualifiers" 14:34:49 ...there is a behavior for toggle with these types of switch 14:36:10 John: as child element or attribute that's next question 14:36:17 ...but still not same as SNB on form control 14:36:46 ...don't dispatch all refresh events to this element in same way as label/hint/alert don't get them 14:36:55 ...actual controls have more behavior 14:37:09 ...same as xforms actions having SNB 14:37:45 Leigh: do we need to drill down further into events etc? 14:38:07 John: don't think so...above was clarification that SNB here is like those other examples 14:38:14 John: child element or attribute? 14:38:17 Charlie: both 14:38:41 I vote for attribute 14:38:49 John: advantage of child elements is you can use @bind 14:38:51 ah yes, bind 14:38:53 good point 14:39:08 I'm in favor of a selected child with ref and bind attributes 14:39:09 Charlie: why not allow short-hand w/attribute or long-hand with element? 14:39:18 +1 to both 14:39:24 +1 to attribute 14:40:19 John: Mark suggests attribute/element pair but where overriding element uses @value 14:40:25 ...we can separate those decisions 14:40:53 Kenneth: I'm ok w/ having both 14:40:57 John: anybody opposed to both? 14:41:00 both sounds fine to me 14:41:07 Uli: don't know why we need extra attribute 14:41:19 ...we already have attr on switch for relevance 14:41:20 Goo point Uli 14:41:27 s/Goo/Good/ 14:41:56 John: good point, extra attribute in our impl is based on idea that switch is container and @ref there is context node for subtree 14:42:04 ...@ref there tends to go at subtree not root 14:42:16 Uli: don't find it intuitive to have two SNB on switch...hard to understand 14:42:24 ... ... ... ... 14:42:55 14:42:56 Uli: another point, to set the binding context we could just use a binding attribute 14:43:23 s/binding attribute/context attribute/ 14:45:10 Uli: how would @selected be evaluated? in what context? of switch? 14:45:33 John: same as other "secondary" attributes...if there's @ref then that context controls context for other attributes 14:46:38 John: so having child element as override gives chance to use bind sites in addition to xpath 14:46:45 Uli: ok, sounds good to have both 14:47:03 John: ok sounds like we have consensus on using both 14:47:08 John: next question is name... 14:47:17 ...don't know why "selected" didn't come up 14:47:38 ...perhaps concern about confusion with case element @selected 14:47:43 +1 for selected 14:47:47 +1 14:47:52 +1 for selected 14:48:30 +1 for selected 14:49:23 Leigh: checking past discussions about possible reasons for not using @selected 14:49:36 ...think that was more related to changing it to boolean on case 14:50:01 zakim, who is noisy? 14:50:12 Steven, listening for 10 seconds I heard sound from the following: [IPcaller] (11%) 14:50:20 zakim, who is here? 14:50:20 On the phone I see wiecha, John_Boyer, [IPcaller], Leigh_Klotz, Steven, unl, kenneth 14:50:22 On IRC I see davidlandwehr, kenneth, unl, RRSAgent, John_Boyer, Zakim, wiecha, klotz, nick, Steven, trackbot 14:50:26 zakim, mute [IPcaller] 14:50:26 [IPcaller] should now be muted 14:50:33 zakim, mute me 14:50:33 [IPcaller] was already muted, nick 14:50:45 Leigh: sounds ok to me 14:50:46 s/shoen/schön/ 14:51:08 John: ok, sounds like it's @selected 14:51:13 Charlie: element too? 14:51:26 John: matching element and attribute yes 14:52:22 ACTION: John_Boyer to write up selected attribute and child element with SNB for data-driven switch, overriding selected attribute on case 14:52:22 Sorry, couldn't find user - John_Boyer 14:52:59 Topic: Case Function case() 14:53:01 http://www.w3.org/MarkUp/Forms/wiki/CaseFunction 14:53:05 John: think there are impls already 14:53:20 zakim, unmute me 14:53:20 [IPcaller] should no longer be muted 14:53:31 ...understand takes parm of ID of the switch, returns ID of selected case if there is one 14:53:54 ...given data-driven switch, there's a possibility of no selected case, would return empty string 14:54:03 Nick: i have an example 14:54:18 ...based on orbean impl 14:54:24 s/orbean/orbeon 14:55:36 John: what's the return value...xs:string? 14:55:43 Nick: related to returning empty sequence 14:55:50 ...more info than empty string 14:55:58 John: for xpath 1.0 it would be just string 14:56:00 Nick: yes 14:56:11 John: namespace qualified the case fn? 14:56:15 Nick: yes 14:56:22 ...need to discuss 14:56:34 ...should fns keep going into global if we're heading to xpath 2.0 14:56:49 John: does xpath 2.0 allow to set default ns? 14:56:51 Nick: yes 14:57:12 http://www.w3.org/MarkUp/Forms/wiki/XPath_2.0 14:57:21 ...yes, we could set default to us, then have to qualify all the std fns 14:57:29 John: painful 14:57:44 ebruchez has joined #forms 14:57:55 Nick: discusses collisions between xforms and xpath 2.0 and diff behavior 14:58:25 John: makes me wonder if we should say for xpath 1.0 we continue as now, but for xpath 2.0 our fns are only accessible in xforms NS 14:58:29 zakim, coe? 14:58:29 I don't understand your question, ebruchez. 14:58:34 zakim, code? 14:58:34 the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), ebruchez 14:58:53 Nick: yes, would be good 14:59:24 +ebruchez 15:00:07 John: if using xpath 1.0, case() should be same location as index()...but for xpath 2.0 would have qualified name 15:00:34 ...gives freedom to treat XForms for HTML continue to be based on xpath 1.0 15:00:43 ...w/o qualified fn names 15:02:15 John: (...missed point about dependencies) 15:02:47 ...index() acts like it creates "false" instance data 15:03:10 ...so xpath expressions w/index() have correct dependency tracking 15:03:21 Charlie: so case() should do the same? 15:03:48 Nick: will check for this behavior and also for no-cases selected 15:07:09 ACTION: Nick to write up delta spec text for case() function in xpath 1.0 style and covering dependency behavior 15:07:09 Created ACTION-555 - Write up delta spec text for case() function in xpath 1.0 style and covering dependency behavior [on Nick Van Den Bleeken - due 2009-06-25]. 15:07:49 John: also good to cover both xpath 1.0 and 2.0 behaviors 15:07:56 ...will need in general for all fns going forward 15:11:36 -Steven 15:11:36 -unl 15:13:42 zakim, who is here? 15:13:42 On the phone I see wiecha, John_Boyer, [IPcaller], Leigh_Klotz, kenneth, ebruchez 15:13:44 On IRC I see ebruchez, davidlandwehr, kenneth, unl, RRSAgent, John_Boyer, Zakim, nick, trackbot 15:13:50 zakim, who is noisy? 15:13:57 wiecha has joined #forms 15:14:00 John_Boyer, listening for 10 seconds I could not identify any sounds 15:14:09 zakim, who is noisy? 15:14:19 John_Boyer, listening for 10 seconds I heard sound from the following: [IPcaller] (78%) 15:14:40 zakim, [IPcaller] is nick 15:14:40 +nick; got it 15:14:48 klotz has joined #forms 15:16:20 zakim, mute me 15:16:20 nick should now be muted 15:16:22 -Leigh_Klotz 15:16:48 zakim, who is here? 15:16:48 On the phone I see wiecha, John_Boyer, nick (muted), kenneth, ebruchez 15:16:49 On IRC I see klotz, wiecha, ebruchez, davidlandwehr, kenneth, unl, RRSAgent, John_Boyer, Zakim, nick, trackbot 15:17:48 +unl 15:18:22 Steven has joined #forms 15:18:25 +Leigh_Klotz 15:18:27 Topic: Dialog 15:18:46 zakim, dial steven-617 15:18:49 ok, Steven; the call is being made 15:18:50 +Steven 15:19:06 Leigh: Erik has implementation 15:19:30 John: have had difficulties in the past with putting UI controls in the dialog and event bubbling questions 15:19:31 sure ;) 15:20:03 John: could discuss a new element, e.g. dialog, containing UI content but referenced from actions or elsewhere 15:20:16 ...UI is referenced not inlined 15:20:25 ...no confusion about event flow 15:20:30 or actions to show and hide a dialog, like it is done in Orbeon 15:20:47 zakim, mute me 15:20:47 unl should now be muted 15:20:48 Charlie: would it be useful to have events bubble out of that context? even if separate 15:21:20 Erik: reviews example 15:21:36 15:21:36 Title 15:21:36 15:21:36 ... 15:21:36 15:22:13 declarations usually at the top level of the document...separate from executing UI 15:22:21 ...e.g. under body 15:22:48 John: could see using this inside repeat as well 15:23:00 Erik: yes, could do that 15:23:19 ...one action to open dialog, another to close 15:23:28 xforms:show dialog="IDREF" 15:23:29 15:23:36 15:23:46 John: is dialog modal? 15:23:54 Erik: have attributes to control that, also on the action 15:24:01 on dialog appearance="full | minimal" level="modeless" close="true" draggable="true" visible="false" 15:25:54 Erik: want to prevent interactions with content under the dialog...hard to implement in underlying js frameworks...block events etc 15:26:01 ...if you want modal behavior 15:26:54 Erik: can close either with built-in close icon or with trigger calling xforms;hide 15:27:15 xforms-dialog-close and xforms-dialog-open 15:27:33 Erik: similar to toggle 15:27:51 Erik: dispatched to dialog 15:28:17 Charlie: do events bubble out of the dialog? 15:28:23 Erik: yes 15:28:42 John: how's that going for you? 15:28:52 Erik: ok, since dialogs are at top level of doc 15:29:02 Erik: might be interesting if dialog is inside repeat 15:29:37 John: trouble in the past with event flow was more with UI content inside of message action inside of trigger...DOMActivate bubbling back up to the trigger 15:30:01 ...trying to close the dialog might re-show the dialog 15:30:16 ...so separating dialog declaration from invocation solves this problem 15:30:51 Erik: yes, but if you have a very simple dialog would be convenient to put directly in the action...but in most cases they're complex enough to warrant separating them from where used 15:31:35 John: also, the act of closing the dialog probably doesn't generate a DOMActivate? 15:31:42 Erik: right, uses underlying behavior 15:31:47 I really like how it is implemented, the only thing that requires some coding is a dialog with an ok and cancel button, because you need an extra instance, and copy between the instances on show and when the OK button is closed 15:32:26 Charlie: what about nick's point of data binding? 15:32:38 q+ 15:32:44 Leigh: yes, what about communication between models or instances? 15:33:00 and transclusion via src 15:33:06 Erik: related to that point, we have flexibility in our impl to scope our model within a dialog 15:33:29 ...dialogs often warrant having own instance data, submission, binds etc 15:33:48 ...don't need to actually nest the model in the dialog to do this 15:34:02 ...for packaging we allow putting the model inside the dialog itself 15:34:17 ...encapsulated function 15:34:52 ...we can set custom context information in show and hide actions so can pass info on invocation 15:35:15 q? 15:35:15 Charlie: could you please provide example? 15:35:40 Leigh: people also want cancel operation 15:35:58 zakim, unmute me 15:35:58 nick should no longer be muted 15:36:41 Nick: need to copy in and out...lots of coding 15:36:48 Leigh: yes, perhaps "submit" back up 15:37:24 Erik: yes, these patterns suggest local data...but copying data in is easy with context info passed in 15:37:43 ...dialog has open event listener to insert that data into local instance 15:38:07 ...passing data out is a bit harder if you want the dialog to be completely reusable...need destination location 15:38:27 John: in the past we have had need for equivalent of @ref but subtree binding 15:38:47 ...to support subtree replacement 15:39:20 ...when dialog was activated it would bind to subtree 15:39:41 ...on "hide" that's a signal to commit data back to external subtree by replacement like submission replacement 15:39:54 Leigh: relates to submission as well 15:40:05 Charlie: also a question of whether binding is live during dialog execution 15:40:18 Erik: XBL speaks to all this 15:40:35 ...preferred way to sync w/shadow tree is by events 15:40:48 Charlie: there's also attribute binding 15:41:02 Erik: our dialogs are not this complex 15:41:06 for a modal dialog, show and hide are good communication points. For modeless dialogs, a more incremental binding is probably desired 15:41:16 perhaps with more events 15:41:21 yup 15:41:27 like dialog-commit event 15:41:54 default processing does the copy from dialog internal data to the bound node 15:42:05 s/node/subtree 15:42:08 we could in 1.2 do the simple case of application level data input/output and generalize with the components theme longer-term 15:42:51 Nick: pattern of ok/cancel with subtree is very common...need an easier way than application level code 15:43:29 John: ref method would be short-hand for two-way automatic communication to happen by default 15:43:39 ...could be overloaded with custom event scheme when needed 15:44:48 Erik: for custom controls in general there's a problem with a component separating internal processing from synching with external instance 15:45:15 Charlie: yes, that's why i was thinking we deal with these aspects of dialog later along with the custom control theme 15:46:22 John: for atomic controls in our impl we have more declarative means to describe formatting as layer around XForms behavior 15:47:03 ...separates custom control behavior from data binding behavior 15:47:48 ...w/o event handlers...it's automatic behavior 15:48:20 Charlie: so perhaps we can scope the function to deal with the simple subtree read/replace case now and expand later 15:49:32 John: declarative templates for formatting get hard when there are composed values...not single atomic field 15:49:42 ...either at UI or instance level 15:49:47 ...like inline dialog 15:50:11 Erik: yes, that's the point...we have the same problem with composites 15:50:14 ...complex types 15:51:45 Leigh: would it support different source and destinations? 15:53:07 ...so putting separate refs on invocation to initialize and on the dialog to say how to return values would support this 15:53:17 Erik: but the dialog shouldn't itself know where 15:53:28 Charlie: the dialog needs to specify the "type" not the destination 15:54:26 zakim, mute me 15:54:26 nick should now be muted 15:54:34 Erik: the separation of submission from send is also problematic 15:54:45 ...so our show and dialog is a bit closer 15:54:57 ...so submission is more an example of how we don't want things to be 15:55:17 Charlie: wasn't saying they should be on same element, just that there are *two* concepts 15:55:23 ...destination and structure 15:57:00 Leigh: dialog lifecycle is like an internal version of submission 15:57:38 I like Leigh's xforms:domination 15:57:49 ...Raman and I talked about "component" and "use" but never got too far 15:59:24 s/and I/and Leigh 16:00:53 John: so you're talking about submitting *to* the dialog 16:02:11 -wiecha 16:02:15 -Steven 16:02:17 -Leigh_Klotz 16:02:21 -nick 16:02:23 -John_Boyer 16:02:24 so just to sum up, you're talking about a submit or trigger that invokes a send, 16:02:25 -kenneth 16:02:27 -unl 16:02:31 -ebruchez 16:02:31 that then calls a submission. 16:02:33 Team_(forms)13:58Z has ended 16:02:35 Attendees were wiecha, John_Boyer, Leigh_Klotz, Steven, unl, kenneth, ebruchez, nick 16:02:48 the submission resource would indicate the dialog 16:02:55 the submission ref describes input to the dialog 16:03:11 and the submission targetref says where to put the result of the dialog 16:03:39 Leigh: Yes, except it doesn't have to literally be those elements. That's just the model. The dialog is an "in the box" web server 16:03:59 Now we're breaking for breakfast/lunch/dinner 16:04:19 when we come back, will continue with dialogue on dialog 16:04:23 rrsagent, make minutes 16:04:23 I have made the request to generate http://www.w3.org/2009/06/18-forms-minutes.html John_Boyer 16:45:25 Steven-mobile has joined #forms 16:59:20 Team_(forms)13:58Z has now started 16:59:27 +Leigh_Klotz 16:59:44 zakim, code? 16:59:44 the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), nick 16:59:50 klotz has joined #forms 16:59:53 +[IBM] 17:00:00 zakim, [IBM] is wiecha 17:00:00 +wiecha; got it 17:00:25 +[IPcaller] 17:00:43 zakim, I am [IPcaller] 17:00:43 ok, nick, I now associate you with [IPcaller] 17:00:51 +kenneth 17:02:33 +ebruchez 17:02:56 zakim, mute me 17:02:56 [IPcaller] should now be muted 17:03:31 Zakim, dial steven-617 17:03:31 ok, Steven-mobile; the call is being made 17:03:33 +Steven 17:04:27 +John_Boyer 17:05:13 Scribe: Nick 17:05:17