W3C Forms teleconference April 7, 2010

* Present

Erik Bruchez, Orbeon
John Boyer, IBM
Leigh Klotz, Xerox (minutes)
Mark Birbeck, Web Backplane [irc]
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C (chair)
Charlie Wiecha, IBM
Philip Fennell, MarkLogic

* Agenda


* Administration

Steven Pemberton: Welcome Philip Fennel. Please introduce yourself.
Philip Fennell: I work for MarkLogic in the UK. I do a lot of consulting with customers XML, XSLT, XQuery, and XProc work and am engaged in XForms work. I've been previously at the BBC and HP Labs in Bristol, where I worked on XForms for Java and SWT. I live in the southeast of England.
Steven Pemberton: Welcome. This is the tail-end of the "previous" working group and we're currently going through re-chartering.

* Rechartering


Steven Pemberton: I believe we got a good response. The management team has an agenda item to consider the issue today. When the new charter kicks in, I think everyone has to re-join.

* Action Item Review


John Boyer: On contact with the new group, should we wait for the announcement?
Steven Pemberton: It's easiest to point to the announcement but you can certain get contact going.

* Encouraging Experimentation with XForms 1.2 features


John Boyer: At the last meeting we resolved to ask implementors to try out features in their XForms 1.1 processors. Should we encourage trying out other features, from the F2F meeting? One is multiple model-item properties. Is there any harm in that? It seems like it's in the same category of "nothing that previously worked would stop working."
Steven Pemberton: Right. In fact, I suspect that many implementations already work with multiple bindings. I've seen some of my forms which do work this way already.
John Boyer: I suspect so.
Steven Pemberton: It sounds like a good plan. Do you want to take the action to post a message encourage?

Resolution 2010-04-7.1: Forms WG encourages XForms 1.1 implementers to provide early experimental adoption of "multiple MIP" resolution appearing in http://www.w3.org/2010/03/25-forms-minutes.html#res_multimip

Action 2010-04-7.1: John Boyer to post messages encouraging to experiment with allowing multiple bindings for the same MIP, as described in the MIP resolution: http://www.w3.org/2010/03/25-forms-minutes.html#res_multimip

* XForms and Deprecating DOM* Events in DOM3 Events

http://lists.w3.org/Archives/Public/public-forms/2010Mar/0049.html http://lists.w3.org/Archives/Public/public-forms/2010Feb/0000.html

Steven Pemberton: Any comments?
John Boyer: We should come to a conclusion.
Steven Pemberton: If we declare it, and SVG has to declare it too, then there would be different definitions.
Charlie Wiecha: Does it bubble and capture the same way?
Steven Pemberton: Yes. I can't answer right now whether it has the same other properties.
Charlie Wiecha: click is odd for VoiceXML, but there may be additional issues if there are differences in semantics.
Steven Pemberton: It's unfortunate for form compatibility.
John Boyer: Older processors will work fine; it's only new versions of languages such as XForms n+1. We could use a version attribute.
Steven Pemberton: Doesn't that allow some forms processors to stop working?
John Boyer: Demand will push whether backward-compatibility gets implemented, or whether it would be easier to fix the forms. It's a Darwinian decision mechanism. The reverse issue is, from the DOM perspective, if they have click and it's required across web browsers (which is all they care about) and then DOMActivate is optional to implement. If someone implements the optional components, what are they going to do?
Steven Pemberton: The spec does define what happens.
John Boyer: So if they have both, do they dispatch both?
Steven Pemberton: That is right, but it depends to what degree you optimize; if nobody has registered for an event you don't have to dispatch it. Bubble and capture work that way as well.
John Boyer: So implementations wouldn't be penalized.
Steven Pemberton: Not if they do it right.
John Boyer: Then I don't see a problem with optional. Aside from web browsers, there are other places that need it. I thought Charlie noted there were some limitations on where click could go.
Charlie Wiecha: That's what I am asking.
John Boyer: Is it any benefit to XForms if DOM 3 lists DOMActivate as optional, if none of the web browsers implement it? What does it gain us?
Steven Pemberton: It gains backward compatibility; you don't have to re-write forms. Not everybody has control over forms. If you load someone else's forms, you can't change them.
John Boyer: And what do we get from having it defined in DOM3? Permission to use it?
Steven Pemberton: Yes, and hopefully it will be implemented in the future as well.
John Boyer: We have a significant investment as a company with using DOMActivate outside HTML in our product. Our tools use it, and we've trained our users, our consultants, and developing our design tools. We'd have to spend a significant amount of money to change it.
Steven Pemberton: Good statement.
Charlie Wiecha: We need to resolve if there are any semantic differences, and whether click can be used only in certain locations.
Steven Pemberton: I'll read the spec for that; someone else should as well.

Action 2010-04-7.2: Steven Pemberton to read http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMActivate and report back on semantic differences and whether click can be used only in certain locations.

* switch/@appearance


John Boyer: Our discussion of UI state got us to the point of seeing that there was a difference between absent nodes and non-relevant nodes. That was an important distinction we haven't properly made before. We tried to make things absent but zombie-like. We also discussed switch, and there were a number of use cases for non-selected cases with variations. The use cases sounded like minimal, compact, and full behaviors of select1, which is somewhat analogous. It seemed like a minimal behavior is like non-selected cases being absent, that compact was like non-selected cases still being non-relevant but somehow more available, and full appearance like using switch for a wizard where the non-selected cases contain controls that aren't shown but might still participate in validity eventing (i.e. fully live but styled display:none). For example, a tabbed switch might show the case labels of non-selected cases. We might be able to describe those cases using appearances.
Leigh Klotz: Chiba used switch/@appearance as early as 2003 and the same for repeat. So we might see if any processors already use @appearance before we start deciding it.
Steven Pemberton: Did you mean repeat or switch, John?
John Boyer: I was talking about switch.
Steven Pemberton: I like use cases for repeat such as labels.
Leigh Klotz: repeat appearance has been used for tables, omitting header rows, etc.
Nick van: I've never used it.
John Boyer: It could have become common practice, such as select/@appearance=minimal not doing radio buttons. Of course, we should see what others are doing already. We could have recommended practice rather than optional, so that mobile devices could do different things.
Steven Pemberton: So, minimal clearly has only the current case being visible. I like the idea of compact being tabbed, or was it full?
John Boyer: I think that a switch currently shows you one case full of things; but there seem to be three things. The compact one is what we're doing now, where the cases are non-relevant, but we have language that talks about what you can do with non-relevant things. A lot of people aren't too happy with that behavior. It would be nicer if the non-selected cases were completely absent. So how do we encode the behavior of being absent.
Steven Pemberton: Now I understand; you mean "absent" as we meant at the F2F.
John Boyer: Sometimes we want absent; sometimes we want non-relevant. And sometimes we want non-selected cases to receive events and participate in the lifecycle (be alive and well, so to speak), and just stylistically cause display:none. So you would have the flexibility to style as a multi-tab switch.
Leigh Klotz: I don't dispute the use cases, but I don't like having the @appearance control behavior.
John Boyer: I started to think about that; is it really that difference from appearance on a select1?
Erik Bruchez: I think so far, appearance is purely presentational and wouldn't impact events or other internal state. It would be considered an important change.
Steven Pemberton: Yes, in the past was CSS for example.
John Boyer: So maybe we need a different attribute.
Steven Pemberton: So these different versions are available in tthe markup.
John Boyer: We could experiment with this in XForms 1.1
Leigh Klotz: Orbeon uses foreign attributes for experimentation.
Erik Bruchez: We use an extension attribute that controls the switch behavior. It's a boolean for xforms-11-switch. It's not very fancy.
John Boyer: Certainly, appearance full is about being fully live and styled. It's not strictly styling. It's saying how should the switch behave.
Leigh Klotz: Do you think you'd come up with more than three if you weren't fitting it to appearance?
John Boyer: Some people want multi-select switch, but I think that's a different issue.
Steven Pemberton: That should be possible with model-based switching.
John Boyer: We're talking about a data-based version of the switch element. It would select all the ones that are listed.
Steven Pemberton: It's an interesting suggestion, which I now understand. I personally would like to think a little bit longer about it.
John Boyer: The only two hard things are avoiding bugs in concurrent programs and naming. I can't think of a fourth case. minimal, compact, and full as value names seem pretty good, though compact is a bit suspicious.
Steven Pemberton: It is more about behavior than appearance. Let's think about it a little longer.

* model/@src use cases

Leigh Klotz: I think Charlie is nearly done with the model/@src feature, but I had some questions about whether it was useful enough. At the F2F we talked about some use cases John mentioned. John, do you have any progress on the use cases for the designer tool?
John Boyer: Not yet.
Steven Pemberton: Next week, then?
John Boyer: Sure.

* IRC Minutes


* Meeting Ends