W3C Forms teleconference January 30, 2008

* Present

Charlie Wiecha, IBM
John Boyer, IBM (Chair)
Joern Turner, DreamLabs
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net
Erik Bruchez, Orbeon
Nick van den Bleeken, Inventive Designers
Roger Pérez, SATEC
Steven Pemberton, CWI/W3C
Uli Lissé, DreamLabs
Keith Wells, IBM

* Agenda


* Previous minutes

http://lists.w3.org/Archives/Public/public-forms/2008Jan/0029.html IRC supplement: http://www.w3.org/2008/01/16-forms-minutes.html

* F2F Registration

John Boyer: Anybody not yet registered?
Leigh Klotz: I am not and I plan to call in.
John Boyer: Keith do we have that?
Keith Wells: Yes, we have full conference. We have 7 in person and 11 total registered.

* F2F First Virtual Day

John Boyer: We agreed to meet for six hours, from 9AM-3PM EST, which is 1400 UTC. It won't be a full eight-hour meeting. I know at least some of the folks on the east coast are going to need a break.
Steven Pemberton: We'll all need a break.
John Boyer: We should arrange for a time to hang up and get back on. 2.5 hours, break, 2.5 hours?
Steven Pemberton: That sounds good.
John Boyer: OK, we'll do that.

* F2F Web Conference

Charlie Wiecha: I'll try to set up a web conference, at least first for the virtual day.
Steven Pemberton: Are we going to be in the Radisson?
John Boyer: How far is the Radisson?
Steven Pemberton: 2.4KM.
Keith Wells: It's a straight shot, but probably not too walkable.
Mark Birbeck: I have an account with Yugma and they give desktop sharing, free phone number, recording...
Charlie Wiecha: Our IBM does not record. But will it be useful?
Mark Birbeck: I can't think of a use for it.
John Boyer: OK, maybe we'll stick with Charlie setting something up.

* F2F Agenda

John Boyer: I think it will be mostly future features. 1.2 on Friday, Monday; 2.0 on Tuesday; 1.2 on Wednesday.
Charlie Wiecha: Sounds like a nice break.
John Boyer: I know we want to get out of first public working draft. OK so we'll run with that. I'll put out topics after this call.

* Forms Newsletter

John Boyer: Leigh, how's that?
Leigh Klotz: I'll take a look.
John Boyer: We can go over it Friday.
Leigh Klotz: We can publish Friday's results then.
John Boyer: On Monday.

* XForms 1.1 CR Typos


John Boyer: I think these are cut and paste errors for datatypes. Is everyone happy to have me do that?

Action 2008-01-30.1: John Boyer to fix http://lists.w3.org/Archives/Public/www-forms-editor/2007Dec/0003.html

* XForms 1.0 TE: Issue with bibliography link


John Boyer: The issue is the shortname link to XML Events instead of the dated version, which is unfortunate in that we don't get later versions. The deeper issue is that the shortname points to the WD for XML Events 2. It seems it shouldn't point to something that isn't a Rec. Is that a fair statement?
Steven Pemberton: It depends on the definition of should. When it is new, it should point to the latest. But a shortname isn't guaranteed to give a Rec. A normative reference should probably use a dated version.
John Boyer: What is our policy going to be in group, domain, and W3C on shortnames?
Steven Pemberton: I am sure it's already defined; I believe it always points to the latest version, end of story.
John Boyer: The W3C document doesn't say that, which is part of the problem.
Steven Pemberton: It says it should point to the latest recommendation. http://www.w3.org/2005/05/tr-versions
John Boyer: We agree with that, but what about the version-specific ones? xforms10, xforms11, xforms20? I think it makes sense to have those numerically-identified shortnames point to the latest copy of the spec if they have major-minor. It's OK now that 1.1 is in CR, but as soon as 1.2 is in WD, I wouldn't want someone to get that. We had talked about some pushback here for two-digit version number so we can properly represent the latest versions whether or not they are recommendations.
Steven Pemberton: Here are examples of shortnames with more than one digit: http://www.w3.org/TR/html401/ http://www.w3.org/TR/html401/ http://www.w3.org/TR/html401/
John Boyer: I know Ian wants us to migrate off 11 because the tr document doesn't provide for it. Meanwhile can we get the XML Events link put back to the latest Rec?
Steven Pemberton: I'll ask about what the practice is, about pointing to latest Rec or not.
John Boyer: Is there any objection to take an action to correct this bib entry and any other ones that are using short names? I might not do that any time soon.

Action 2008-01-30.2: John Boyer to ensure that all bibliographic entries in XForms 1.0 do not use short names.

John Boyer: As many of you know, the ODF spec using the XForms model and uses the XForms shortname.

* Access control WD review

http://lists.w3.org/Archives/Public/public-forms/2007Dec/0015.html http://lists.w3.org/Archives/Public/public-forms/2007Dec/0012.html

Leigh Klotz: Dave Orchard has weighed in with some comments.
John Boyer: It looks like it may be changing then?
Leigh Klotz: So we should wait.
John Boyer: Or maybe we can just ask them to consider XForms submission when they do the changes.
Leigh Klotz: Even if they put a blank section in for now. OK, I'll do that.

* Model driven switch with case attribute


John Boyer: There are selected attributes on cases, but it's not clear how things work in repeat. We'd like at least the chance to have a straightforward method to have a switch driven by data in the model rather than by hidden data stored in the UI that can't be captured across save/reload. The straightforward proposal is an attribute on switch, perhaps called case, with an XPath expression evaluated in the context of the ref or the in-scope evaluation context, resulting in an id. This would override the selected attributes on cases. toggle would then select a new case, but that would push into the referenced node into the case attribute.
Charlie Wiecha: That does make sense. id is one pattern; I wonder if there's another pattern with a looser coupling, such as pattern matching.
Erik Bruchez: It seems there is a strong parallel with select1. select1 is used to select a value, which is not the goal here. Is there a way to make the syntax closer. Perhaps cases can take labels, or xf:value.
Charlie Wiecha: That's the direction I'm thinking as well.
John Boyer: That's pretty clever. It also opens up the door for multi-case switches; we have select1 and select. select is driven off a space-separated list of values; we could consider more than one case at a time.
Charlie Wiecha: I wasn't going to go there but I did think of that, too. It then becomes more like a production rule system.
John Boyer: We do have a related use case that Nick and Erik have been onto for a while, with multi-case switch; it could easily move to 1.2. They wanted the other cases to be live to still be able to detect invalidity; somehow live and 'on top.' Maybe that's too far and we stick to one case being selected and an attribute on switch that says whether non-selected cases are in the XForms 1.1 zombie state.
Charlie Wiecha: Let's consider Erik's case of the analog of select and select1.
John Boyer: A different element.
Charlie Wiecha: With consistent syntax.
John Boyer: Are people liking this? A label element and a value element in each case? select off of that somehow?
Mark Birbeck: I've always been against extending case in this kind of way. Erik's summarized it quite well. There's a difference between those things in the model and those things that aren't. It gets confused. I've always seen case/switch more like a dropbox; whether it's open or closed is irrelevant for the model. That's not to say there's not use cases for it, but why not come up with new element for them. For example, the way Erik's putting it, sometimes we want to reflect the value into the model and sometimes we don't. So extend select. The third way is Charlie sometimes wants the model to control the way things appear. You could do it with group ref=.[...] and say it when conditions are true. I'm agreeing we do need something: ui only, model reflected in ui, ui reflected in model. Then let's work out the best way to achieve those use cases, rather than adding an attribute to case.
John Boyer: I'm not proposing an attribute to case ...
Mark Birbeck: There's two ways to change it: user interaction (toggle, etc.) not reflected in model, and then if we change in the model, we have to work out issues about conflicts, loops, etc. These would be unnecessary if we had user choice switch/case where we don't care until they're done, and sometimes the wizard approach.
John Boyer: The group approach is not appealing. It's hard to tell a pile of groups are working together. A containment element gives you the idea.
Charlie Wiecha: ...
Mark Birbeck: Maybe I've misunderstood, but you just reminded me. The way we implemented switch and case is that it toggles all child elements. Maybe we're not so far apart. switch is a controller and case is an anonymous thing. Maybe we can have a generic controller, case or group inside, with different rules.
John Boyer: I do. I see case as a group of controls with a different name because of the parent.
Mark Birbeck: In our Javascript version, switch with div children functions the same way. There's justification for validation, but not for functionality.
John Boyer: Do you really have to wrap it in a case? It doesn't seem like a big deal from a design tool, but maybe in a text editor.
Mark Birbeck: It's not the typing. The key aspect of switch is that the switch element and the id of the children. There's no reason to require xf:case.
John Boyer: Toggle tells switch the id. It would be cool if it would switch and push the value into a referenced node. Toggle then takes on a little bit of setvalue.
Mark Birbeck: I can imagine you convincing me of that. So if we had a toggle-fired event with the value.
John Boyer: In fact it's not called a case attribute, but I do have an implementation of this under a foreign-namespaced attribute. If someone does a setvalue or UI for the data node, then that does act like a UI binding and toggles the switch, which is pretty handy. Then I can use a separate control like a select1 to drive it in a more data centric way. It opens up easier control opportunities than what I had before.
John Boyer: So the proposal for me is to pursue writing up these things we've talked about as a strawman for 1.2.
Charlie Wiecha: Can you summarize where we got to?
John Boyer: Please correct me if I'm wrong. I didn't hear anyone say they didn't want to do this for 1.2 After discussion with Mark, it sounded like he could imagine it. It seemed like a secondary attribute on switch would be useful, to contain an XPath expression resolving to a node to have a two-way binding to switch. To Mark's point, whether switch has to be limited to case as today and instead select among child elements, then calling the attribute something other than case might make sense; maybe state.
Leigh Klotz: I don't see anything wrong with leaving it called case.
John Boyer: If we want to open up the content model it might not be advantageous. Or just use case.
Charlie Wiecha: It implies it's not really switch anymore.
Mark Birbeck: Part of the reason I had been saying the item under select can't take arbitrary markup was in terms of reflecting it in the instance, all the architecture is there, as Erik says with select1. The bulk of the change would be the content of item would be the same as the content of case. We kind of need to go that way with maps. I have a select1 that allow you to choose the URI of a video. The items in the select1 are video showing, using XBL. You need to do the kind of UI people expect nowadays.
John Boyer: I can see opening up select1 to that possibility; but what might a basic author might think? Creating groups of controls and switching them might not be select1. We could allow group in the item syntax, but it also seems to me that there's a lot more basic people who will tend towards choosing switch.
Mark Birbeck: You're right. If you've got to reflect the value of this video then you would move from select1; if they start with video clips and get the user to choose one that might be switch case.
John Boyer: And possibly make the select1 with item labels that are the thumbnail; then that changes cases.
Mark Birbeck: Say you have 4 videos: the label of each is the mini-version of the video. It's a radio button.
John Boyer: Sure. Maybe the switch/case might pop up on the right with the video you chose.
Leigh Klotz: [irc] i see some similarity with xxf:dialog and the proposed xf:dialog as well, in terms of expanded content models
John Boyer: People create the switch, then the selector that drives the switch through data. This happens using the designer tools.
John Boyer: OK, there's debate about whether to call the attribute case. It kind of makes sense do that that. We have case/@toggle and the child element as well. The semantic we're projecting is that we're selecting cases in a switch. So either way I can write it up with case or without. Does that sound reasonable.
Charlie Wiecha: I think it's going in the right direction.
John Boyer: The last bit was the modification to use a value element rather than an id. Does that sound like the way we want to go? Originally I thought of using an id, as with toggle. What came up during this conversation was to question that.
Charlie Wiecha: It is a bit of decoupling between the model and the UI.
Steven Pemberton: I agree. It doesn't seem quite to match.
Leigh Klotz: A number of "little languages" these days allow switch/case with calculated values rather than manifest constants so that seems useful anyway.
Roger Pérez: [irc] an xpath boolean expression to the selected attribute of the actual case instead of the new att?
John Boyer: ...
Steven Pemberton: If we'd chosen something other than id in the beginning we'd have never had the repeat problems.
John Boyer: Not for switch but we had id on input and select1 for setfocus. So we had the general problem.
Mark Birbeck: Which is how it got solved.
John Boyer: Roger asked about selected. My own personal preference is to use switch to select a single case. Pretty much anything goes then, and the author has to work out that one can be true; it seems like a multi-select capability; I'm not sure that's what this widget is. By comparison it seems easy from a design to drag-and-drop and gesture data on to a switch to produce a binding. So I think a single attribute of the switch is better, because it's about th switch.
Nick van: [irc] you have also a problem if the value of the switch doesn't results in an id of a case in the switch
John Boyer: We'd be changing to have a value element within each case; it would choose a case based on value element. It's then like select or select1; there's precedent.
Leigh Klotz: You'd get out of range.
John Boyer: With empty?
Leigh Klotz: With non-empty but not an id in the list.
John Boyer: I buy out-of-range.
Leigh Klotz: But you'd get a binding error if you did it with markup. So can we say you can use switch/ref only with case/value? Those co-occurrence constraints are hard to express.
John Boyer: I like what Rafael said if we consider a value attribute.
Nick van: [irc] if we have <case value=""> then we can make in sync with select and select1
John Boyer: I hadn't realized a attribute was considered; just a child element.
Charlie Wiecha: This is what I thought.
Mark Birbeck: This is what I don't want. I think deciding which to prioritize is a problem. If you go on the id, the user can select one of the cases; the model can update. They can stay in sync. If someone selects a different case, the expression that makes another case selectable hasn't changed. Changing the id is ok, but if it's selected by id or by expression.
Leigh Klotz: This isn't the selected proposal where you can have such conflicts; it's switch/@ref sets the value and the case/@value is the one matched.
Mark Birbeck: So switch becomes select1.
John Boyer: Say you had a select1 with items; the ref chooses leaf nodes, but...
Mark Birbeck: Sure but if the items in the select1 need to come from a different place, then we have other ways to do that. It seems quirky to turn switch/case into select1 and we're losing the distinctions.
Nick van: [irc] I think it is the same as select1, it is only a display issue of select1
John Boyer: The usual semantic of select1 is to choose the value; the usual semantic of switch/case is to display a group. If we throw group into select1 we lose the semantic of select1 then. switch is then a container form control and select is an atomic one.
Mark Birbeck: Rather than becoming an output control, it becomes an input control. Group isn't an input. Output isn't an input. Switch and case aren't inputs, at the moment. It's one thing to enhance them and another to change them into something else.
John Boyer: There are states that exist in the UI that we have no way of capturing in the serialization.
Mark Birbeck: There may be other ways of reflecting that back into the model other than running switch/case into select1; perhaps the index function as in repeat. There may be other ways that don't require us to bend switch/case to become an input control.
John Boyer: So case(). It still lacks automaticity. When a form gets initialized, the switch could automatically decide what case is selected based on the case attribute. With a function, you still have to write an xforms-ready handler.
Mark Birbeck: That's why I have problems with this. The current switch/case uses the attribute, and then toggle. In the model we're now discussing, those two phases get blurred. We'd have to set the instance data. So we could have the enabled attribute an expression. It doesn't have to be so flexible that it's no longer switch.case
Nick van: [irc] and when you change data you should add a change-value listener that switches the case
John Boyer: Suppose we did turn the selected attributes of cases into XPath expressions; that makes it easy to have data drive the switch, but then when the you toggle it's in conflict.
Mark Birbeck: I was thinking of just at initialization time.
John Boyer: Initialization is tricky. When it's time to go home, you save, restore, and then initialization kicks in and you can't pick up where you left off.
Mark Birbeck: I don't disagree. But I just don't think switch/case is the right vehicle. It already exists as a very UI-based thing. I can imagine the UI binding because that conflict doesn't arise, but when we get to general instance data, it does.
John Boyer: To be clear, with IDs I was talking about two-way communications.
Charlie Wiecha: I think that makes Mark more comfortable.
Mark Birbeck: Yes, it's the case/@value that makes me uncomfortable.
John Boyer: Me too.
Leigh Klotz: I don't see the sync problem; I see the select1 issue.
Mark Birbeck: If you have an id it's always synchronized because it sets the value. But I have case whose value is non-smoker, a case could be selected on the basis of information that's non-selected, does it toggle Y?
Leigh Klotz: I don't see how it's inconsistent if it's exactly the same as select1. Just adding ref and value to switch and case won't cause inconsistency because it's precisely select1 with a different UI content model.
Mark Birbeck: But it isn't consistent or the same because value is evaluated to determine whether it selected.
Leigh Klotz: No, it's just like in switch case.
Mark Birbeck: I had misunderstood the proposal.
Leigh Klotz: I think you still don't like it but it isn't inconsistent.
Mark Birbeck: Yes, it's pointless.
Charlie Wiecha: This was my proposal from an hour ago.
John Boyer: <switch ref="some/tree" case="@selected"><case value="justLikeID"
John Boyer: If @selected node contains the value that equals the value attribute then the case is selected

Mark Birbeck: I saw on someone's blog recently, separate instance data just for UI controls. We do this too. I think we could make this fairly simple though.
Erik Bruchez: [irc] same here using a separate instance is often done also to handle controls relevance

Charlie Wiecha: One of your objections was the state variable is in model and not the UI. Maybe if we had some dynamic aspects of state in the UI we could handle this.
John Boyer: If you save the data, you've lost it. switch/case and repeat indices are about it. It's important for digital-security and document-oriented aspects.
Charlie Wiecha: We could still treat it as data but have it at a remove somehow.
John Boyer: The processing model isn't hard; it's just like select1. But I need an idea of whether we're going to do this or not for 1.2. Let's pick that up on Friday.

* IRC Log


* Meeting Ends