W3C Forms teleconference March 16, 2011

* Present

Alain Couthuries, AgenceXML
Steven Pemberton, CWI/W3C (chair)
Leigh Klotz, Xerox (minutes)
Philip Fennell, MarkLogic
John Boyer, IBM
Erik Bruchez, Orbeon
Kurt Cagle, XMLToday

* Agenda


* XForms F2F

Steven Pemberton: Nick can't travel after June and that pushes us into May but it's already blocked off. Unless we ask Nick to join remotely.
John Boyer: I will have a difficult time getting travel approval.
Steven Pemberton: So this may be a virtual meeting. As long as people turn up.
John Boyer: We've gotten decent work done.
Steven Pemberton: We could meet, work on action items, and then come back.

* XForms WG Virtual meeting

Steven Pemberton: So we need a date and I'll do a questionnaire.

ACTION-1783 Steven Pemberton to send questionnaire for next virtual F2F date.

Leigh Klotz: We should move this list to a wiki page. http://www.w3.org/MarkUp/Forms/wiki/FtF_2011_Virtual_1_Agenda

* XBL2 / HCG Meeting

Steven Pemberton: WebApps is willing to let go of XBL and wants to know if we want to take it on. It gives us the power to do what we want, such as use XPath selectors.
Leigh Klotz: Is the browser-vendor work going forward?
Steven Pemberton: We didn't dicsuss ut.
Kurt Cagle: They appear to have backed away from the shadow-DOM work. It didn't fit from their standpoint. They're going so many directions right now and it's low on their priority stack. There's been some experimentation but it's nowhere near close, except Dimitry Glazkov's component architecture. It's the second candidate for a behavior specification. There's no spec at all.
Steven Pemberton: I'd be interested to know what others think. Is this horrifying, interesting, brilliant?
Kurt Cagle: I think it's something we should probably be doing. There are significant advantages to being able to have the specification here. There are implementations out there with a basis other than HTML makes sense, but to do that we have to have an underlying behavior specification for binding it on. An HTML version with that simply won't happen. Cameron McCormack said he hoped to see SVG with an XBL-type behavior independent of XForms. Realistically I think it's either us or SVG, but I don't think it's for them now. Realistically it's closer to Forms WG.
Steven Pemberton: And you're willing to put some cycles into it.
Kurt Cagle: Yes, absolutely.
Steven Pemberton: John, do you have XBL?
John Boyer: There is some XBL-like stuff in Ubiquity that Mark was working but we haven't heard from him on it.
Steven Pemberton: I understand he's become CTO of a startup.
Steven Pemberton: What do you think about XBL?
John Boyer: I can't help but think it's not great news. It's another fairly large and complicated spec to take on ourselves. It's an uphill battle. I think it's a powerful paradigm but it's not going to appeal to garden-variety authors. It's more about implementors.
Steven Pemberton: Erik?
Erik Bruchez: As usual, I agree with John on the fact that the work if we take over is quite significant. In our implementation, lots of users find the XBL component support one of the best aspects of it. So it is something that has a lot of value for implementors and for those who need to develop their own controls in XForms. So the whole concept of being able to define components and bring them to life in an XForms or XForms-like context has a lot of value. It goes way beyond XForms and dates back to Mozilla. Although XBL2 has kind of died, a lot of people see value in the concept. One reason we'd started looking at components in the WG is, let's say you've never heard of XForms and you look at the specification and see what you have in XForms, it's very limited. The controls are very basic. HTML forms are likely to add more controls and basic widgets, but that's a basic set. Nowadays frameworks like Dojo and YUI have much richer sets of widgets. There's a temptation to look at XForms like another framework and see nothing appealing about widgets or building advanced controls. So that's one of the erasons why as a WG we started looking at that; there's a real need for more controls. In our implementation experience, it's been one of the best things we've been working on in our own product. I'm a little torn: on one hand it's a clear use case and the requirements are clear, and what we want to achieve is clear. But on the other hand, the amount of work to bring that to a specification is daunting. If we're talking about cutting down XBL2 to what we've implemented is quite a lot of work. You'd have to go through every single line of the spec to check, or ask if it should be implemented as well. Even without adding new stuff that would specifically help XForms, it's a lot of work. Especially since as the Forms WG we need to come out with XForms 1.2 and that's going very, very slowly. There's been some progress but we still have a big push needed to get even to a first draft. If Kurt has resources to work on it, maybe that changes things a little but, but there would still be an impact on other group members to erview, comment, and discuss.
Steven Pemberton: Anyone else?
Leigh Klotz: I'd like to know where Dimitry Glazkov's is going and what the WebApps and HTML5 people are going and not go another direction. Also I think we should let Kurt work on this but with a date that doesn't interfere with XForms 1.2.
Erik Bruchez: I'd also like to know if the Google folks who were interested in this a f ew weeks age are still going forward.
Kurt Cagle: They said a lot of the Chrome engineers who have looked at XBL have no interest in pursuing it. If they're doing some other related architecture it would be worthwhile ask. We should have a certain degree of assurance that our work is not for nought.
Steven Pemberton: Art's Poll: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0874.html
Erik Bruchez: Ian said he expects Dimitry's work to be eventually in the HTML5 spec. So major aspects of XBL folded into HTML5.
Kurt Cagle: I didn't see that, but I'd have to go read it again.
Erik Bruchez: They like the use cases. It will be useful to us only if and when they implement it and have some first draft of spec.
Leigh Klotz: I think XForms as a declarative, markup interface to native facilities is a good story: submission for XHR, XML Events for DOM Events. It would be good to have some flexibility to change what our component architecture would be if HTML5 provides something underlying using color-coded squiggly braces we can still markup-wrap it but it may change.
John Boyer: I put components lower on the priority list than some existing XForms 1.2 work that we need done for our implementation.
Leigh Klotz: I think components is blocking some XForms 1.2 work and we should have at least a story.
Kurt Cagle: I agree with Leigh; I would start with a new requirements document. XBL2 was overtaken by other developments: it's a pre-AJAX spec that's now orphaned. There are a lot of things we need to look at in new use cases: server-side components, web events, whither JavaScript, etc. It would be worth the effort to put together a requirements document and then see if it's worth pursuing.
Erik Bruchez: We shouldn't give on this, completely. It's a burning need for me, but there are other things that need to get done. We can't come out with a component architecture and not finish XForms 1.2. I also feel that Mozilla has limited resources and must work hard to keep the browser alive from competition, and I don't think it's a lack of use cases. Once they get hardware acceleration etc. out, things like a component model will come back in the next year or two. So I think we should keep that in mind and write something more solid on the WG Wiki as a requirement document as Kurt's suggest, and clarify our vision of what we need. I can contribute to that in a limited way and definitely participate, a few days of work to frame what we need. Taking over the specification would be a full time job. We can start small and see where that takes us.
Kurt Cagle: I think it would probably be good to talk. My recommendation is that we go back to WebApps and say we're interested in taking on the spec but for homework we need to resolve what "forward" means before we commit.
Steven Pemberton: We also might not have the two implementations.
Kurt Cagle: There's only one XBL2 implementation and it's unsupported. We need to ensure there are a couple of working ones. Having said that, I may be in a position (indirectly) to be working on a component architecture. There are significant advantages to marrying a client/server component model with an XML database. So that might jump-start some implementations.

Steven Pemberton: What are our next steps? It sounds like we can give this to you to lead, Kurt?
Kurt Cagle: Definitely.
Steven Pemberton: So our response at the moment is that we want to investigate the possibilities, but we have some worries about being able to find enough time and implementations to conform to the spec. We're currently investigating how we want to do.
Leigh Klotz: And we don't want to proceed in isolation of component work going on in Webapps.
Kurt Cagle: I agree.

ACTION-1784 Kurt Cagle to provide proposals for XBL requirements and use cases.

* Note 2 on XForms 1.1 computational dependency definition. Short-circuting


Steven Pemberton: As I remember, we decided to take out some bits from the current algorithm and say what should happen rather than now.
John Boyer: I think I have an action item to come back to the group with something. There's nothing further to discuss.
Steven Pemberton: So we're waiting on a proposal for interoperability without being to specific about how the implementation should work, a new description.
John Boyer: Right. It's overdue right now.

* label/@for, @appearance

Kurt Cagle: I am working on a proposal for early next week.

* JSON Serialization / Badgerfish


Steven Pemberton: Awaiting XML Prague publication of paper by Alain Couthures.
Alain Couthuries: Publication is next week.

* XML/HTML Task Force

Kurt Cagle: Norm Walsh sent out a note saying they would meet only as needed now.

* Configurable delay for incremental


Leigh Klotz: We discussed this and decided not to do it, but now two implementations (betterForm and XSLTForms have done it).
Steven Pemberton: How have they done it?
Leigh Klotz: @incremental in ms.
Erik Bruchez: Do you feel it needs to be done by the author on a per-control basis? What if you want all to have the same delay? (We have an application setting.)
Leigh Klotz: I brought it up but the group said it would be better to do the something adaptive.
Erik Bruchez: It's not how I'd expect the feature to work that 17 characters producing 17 server round trip. We should clarify that incremental doesn't mean every keystroke sends an event.
Steven Pemberton: Alain?
Alain Couthuries: Using the JSON API with wikipedia it's too slow. The responses came back slowly. It was better to wait for 4-5 keys. It was a nice way to describe it. The submission is to an external server.
Leigh Klotz: When I proposed this before that's what we discussed but the group decided that the application should decide how frequently based on load.
Kurt Cagle: Maybe we should re-address the issue. I can see an argument for saying you don't want a response until the typing is done. I think it's an author decision.
Erik Bruchez: Recap: Maybe I'm wrong but it's clear to me that the specification doesn't require an event for every keystroke: you don't have to tab out. For us, you need two delays: (1) while the user is typing you get an event every 1-2 seconds and (2) if you type quickly and stop typing, dispatch an event. You notify the application regularly. If you want keystroke you should listen for keydown events. Given this, I'm wondering what @delay would do. It might go too far. I don't see the need for delay preventing dispatching every keystroke.
Kurt Cagle: I don't necessarily see it tied to a key event. Let me give you some thinking from a database standpoint: chances are I'm going to want to make sure before I send information back that I have enough query characters to download a bunch. So if I query and get all a back, that's a fairly general query. If I have a minimum of a name, you would use delay as an optional field to let the user type enough info and trigger only upon receipt of a decent key. Whereas if you don't have something like that it's going to vary by implementation as to when the trigger is.
Steven Pemberton: It sounds like we're not yet finished with this topic but our time is up. We'll have to put this off for another time.

* IRC Minutes


* Meeting Ends