W3C Forms teleconference October 27, 2010

* Present

Alain Couthures [left early]
Erik Bruchez, Orbeon
Leigh Klotz, Xerox (minutes)
Philip Fennell, MarkLogic
Steven Pemberton, CWI/W3C (chair)
Uli Lissé [irc only]
John Boyer, IBM [arrived late]

* Agenda


* Previous Minutes

* XSLTForms Extensions

http://lists.w3.org/Archives/Public/public-forms/2010Oct/0005.html subforms, rich widgets, etc. Can Alain summarize?

Alain Couthures: The extensions are about subforms, and widgets built with Dojo. It's a big change in XSLTForms, and it's quite interesting. The subforms are interesting and useful in some cases. I have to see what's possible with the widgets.
Steven Pemberton: What are rich widgets? Controls that map to instance?
Alain Couthures: I haven't seen any yet. It's based on Dojo. Everything possible with Dojo can be integrated.
Steven Pemberton: For example?
Alain Couthures: I don't have any examples yet.
Steven Pemberton: And what are subforms?
Alain Couthures: A way to a form inside another one. The modules are in the body and they can be loaded and unloaded.
Steven Pemberton: Do you submit to the upper form?
Alain Couthures: I don't know yet. As far as I have seen, the models are fairly independent.
Steven Pemberton: Do you think there are lessons we can learn from these?
Alain Couthures: I really think subforms is interesting for real applications, especially in a client implementation.
Steven Pemberton: How do we find out? Documentation? Try it out?
Alain Couthures: I will contact the author.
Steven Pemberton: I shall take a look at it.

* Dependencies for XPath Evaluation

Question from Alain Couthures http://lists.w3.org/Archives/Public/public-forms/2010Apr/0031.html http://lists.w3.org/Archives/Public/www-forms/2010Apr/0024.html

Alain Couthures: In XSLTForms, dependencies are stored. Every time refresh is required, depending on the modified nodes, the expressions are re-evaluated. There is an algorithm. For circular dependencies, when detected re-evaluations is started again. It works as it should. For dependencies, I have added the possibility to, depending on ancestors, re-evaluation is performed also. I sent the familiary example evaluating for strings and children, and now it works with XSLTForms. It's quite useful when XSLT Transformation is performed, becuase just one child has been modified.
Leigh Klotz: Do you still have the restriction that each bind element can be only one node?
Alain Couthures: Yes, it can be removed, but I haven't.
Steven Pemberton: You do special work to check to see that something hasn't already been bound?
Alain Couthures: Yes.
Steven Pemberton: Would it simplify your work to remove that test?
Alain Couthures: Probably.
Steven Pemberton: OK, anything else? Alain, thank you for staying.
Alain Couthures: See you Monday.

* Lyon Teleconference Times

Registration http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/

Steven Pemberton: Uli isn't coming. It will be Nick, myself, Alain, and Lars Windauer from Betterform. I must book teleconference times.
Steven Pemberton: We'll be on from 9AM. This Sunday, Europe goes back to winter time and stops daylight savings time. So we go back an hour. So it will be an hour later for the US. So it would be what you now see as 10AM.
Erik Bruchez: So that's 1AM our Pacific Time. I might call in early in the morning.
Steven Pemberton: We end at 5PM.
Erik Bruchez: That's 9AM Pacific Time.
Steven Pemberton: I will book the conference tomorrow and post the teleconference code to the mailing list.
Leigh Klotz: So it's MTRF and not Wednesday?
Steven Pemberton: Yes, Wednesday is the TP day.
Steven Pemberton: I'll be there Sunday evening. Raman will be around; he might join for a while. The other person I'm hoping might drop by is Michael Sperberg-McQueen, though he also has other groups to go to.

* Lyon F2F Agenda


Steven Pemberton: Let's see if we want to add anything. We have 33 items, quite a lot to get through.

* XBL2 and WebBL

http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0055.html Art Barstow proposes splitting XBL2 into two parts

Steven Pemberton: I have no news.
Leigh Klotz: It's a little different from DOM Events / XML Events, becuase it's the common model that they want to change, not the XML expression on fhte syntax. In this case, it's the syntax that stays the same and the processing model changes. So perhaps the idea would be to use optional modules, for example for namespace support.
Steven Pemberton: I'll try to talk about it with the Team in W3C.
Leigh Klotz: I believe that anything in HTML5 for XBL will be a benefit from all processors from Ubiquity to Orbeon, but we also need the XBL2 specification to move forward as we're using it outside HTML.
Steven Pemberton: I'll try to talk about it with the Team in W3C.

Action 2010-10-27.1: Steven Pemberton to discuss XBL2 with W3C Team.

* XForms and Deprecating DOM* Events in DOM3 Events

New thread from TV Raman, Jonas Sicking, et al.: http://lists.w3.org/Archives/Public/public-forms/2010Oct/0017.html

Steven Pemberton: To me, deprecate means it will be removed in the future. Some responses indicate that it will be deprecated but not removed, so I don't know what that means? The risk is that they will later remove it anyway.
Erik Bruchez: I didn't look at the wording; it seemed that implementations (bugzilla) say that DOMActivate report is being removed and is not being added. So it's clear they're not going to use DOMActivate.
Steven Pemberton: In web browsers.
Erik Bruchez: There was also a reply that abstract activation is useful but DOMActivate isn't it. I didn't get the feeling that anyone was keeping it around.
John Boyer: The deprecation usually means, as in Java, that two or three versions later they remove it. With W3C, they are actively removing it now. When they exit CR, deprecated feature will be removed then, before Rec.
Steven Pemberton: Right.
John Boyer: Current XForms is not based on DOM 3 events.
Steven Pemberton: Yes, DOM 2 Events.
John Boyer: So they are creating a problem where we have to have XML Events = DOM 3 Events + DOMActivate, or we have to move XForms from DOMActivate, which is not without cost.
Steven Pemberton: Apple had proposed (in the link) to all hardware events to abstract into a set of intent-oriented events, rather than hardware-oriented. That's currently in discussion. The editor of the Events spec said at HCG they would like to go in that direction. They're going in both directions at once: remove abstract DOMActivate and add new abstract events. So instead of DOMActivate, it will have a different name.
Erik Bruchez: Historically, in mouse-oriented XForms processors, when we tell authors they have to use DOMActivate, they get puzzled. An event called click (even if not a click) ... right now browsers dispatch the click event even if there isn't a click, for example if there is a space. For authors, the name "click" is much more intuitive and it's understood that it might be space bar, return key, enter in a text field, etc. From that perspective, migrating to the DOM 3 events names isn't a bad thing for XForms. For now, DOMActivate, DOMFocusIn and DOMFocusOut need to be kept around in XForms.
Steven Pemberton: It would have been nicer to call it Activate but they didn't have namespaces. The reason you want these abstractions is for platform independence, not just because there are different ways to activate the button. In those days, click didn't work across browsers. For Apple, with teh iPad, they have gestures and other things that you do differently, so they're coming with suggestions for doing these things abstractly instead of concretely. The name "click" is fine until you want to distinguish between click and some other activation. The proposal from Apple is to go in the direction of abstraction, with hardware and abstract events, so you can choose.
Erik Bruchez: That sounds like a good solution.
Steven Pemberton: It seems like form authors will be more receptive to using click, unless the world moves entirely to touch interfaces. Right now, most form authors will be comfortable with just a click event. If you want to make a distinction, it might be rarer.
John Boyer: I agree with Erik, that click has come to mean the device-independent DOMActivate; the new hardware things will have to become HClick or something.
Leigh Klotz: Is that Apple message in another thread? Can you send that in to this thread?
Steven Pemberton: http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html
Erik Bruchez: Will they pick "DOMActivate"
Steven Pemberton: We've had DOMActivate for 10 years now and the DOM3 group is saying that they're sorry we'll have to change our language and they're making a new name for it. They seem to be beginning to understand abstract events and feel that it needs to be re-invented. I don't care about the name but I do care about them removing something that's been in use for 10 years.
Erik Bruchez: How they they reconcile browser vendors who have never implemented it with wanting to keep it in the implementation?
Steven Pemberton: So perhaps they could make it optional? What I want is that languages that do use it could carry on, and understand that it's the same event. In mixed-namespace documents there would be a risk of different semantics and different "DOMActivate" events. If we say it's optional then the browsers don't have to.
Leigh Klotz: So why not say that, making it optional?
John Boyer: They'll need a reference implementation that needs to pass the test. They might not allow passing specific tests without the whole test suite.
Erik Bruchez: The reaction to optional features is that it should be mandatory or removed from the HTML5 perspective. Maybe what's lost on them is that other people are making use of the specifications. I would imagine HTML5 would support DOM Events and see that they would be reluctant from their standpoint.
Steven Pemberton: If this were HTML Events I'd be OK with that but it's DOM Events, and for a wider range of specifications. I understand that for the moment that HTML5 is .... they shouldn't use this one spec only for HTML events and forgetting other specs.
Erik Bruchez: That needs to be made clear.

Action 2010-10-27.2: Steven Pemberton to propose making DOMActivate optional in the light that there needs to be a single definition point for a definition already in place for ten yewards, to point out that HTML5 is not the only consumer of DOM Events, and that there are already DOMActivate implementations in DOM Level 2 implementations which would likely provide CR exit for the DOM 3, and that the Apple User Interface Independence proposal at http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html strengthens the future case for abstract events.

* Improved UI Events


Steven Pemberton: Erik?
Erik Bruchez: My proposal is prior to our discussion and equates relevance with visibility.
John Boyer: If this takes less than a day to sort out I'll be amazed.

* P3PType


Steven Pemberton: We're proposing to deprecate it. Is anyone using it? The potential advantage is that it adds a hint to the markup that helps with filling it in. I would very much like to form software that recognizes that the form is asking for particular information so I don't have to type it in. It could already fill in my name, for example. So either we don't deprecate it, as it was intended to make privacy issues obvious, or possibly that we generalize it to use RDFa and give the same properties with an extension for other properties without changing p3p.
John Boyer: We want to have alert and hint at the node level instead of the form control level. There's a lot of possibility for other MIPs about data, even though it surfaces through the form controls.
Erik Bruchez: I believe P3P has to go; it's clear that it's a dead technology that nobody is implementing. There are no implementations for ten years. We can't re-write it. Whether or not we want the features, P3P isn't the way to do it.
Steven Pemberton: If we generalize it to a thing to hang properties off, an implementation could use that thing to hang things off. We don't need to specify the values; they could use P3P, or other values more generalized, like the class attribute. The P3P data would go there if you need it. So if John has some facility, there's a place to hang it.
Erik Bruchez: I don't think it should be called P3P.
Steven Pemberton: That's fine.
Leigh Klotz: This sounds like a single MIP containing space-separated list of QNames. We've also heard about custom MIPs with multiple MIPs. You also proposed triples.
Steven Pemberton: I mentioned RDFa and that incorporates triples.

* F2F Starts Monday 9AM CET / 1AM PDT

Call-in details TBD

* IRC Minutes


* Meeting Ends