W3C Forms teleconference October 7, 2009

* Present

Erik Bruchez, Orbeon
Steven Pemberton CWI/W3C (Chair)
Uli Lissé, DreamLab
Charlie Wiecha, IBM
Leigh Klotz, Xerox
Nick van den Bleeken, Inventive Designers

* Agenda


* Previous Minutes


* Working-Draft Review


Steven Pemberton: Should we review this?
Charlie Wiecha: It's a best-practices document.
Erik Bruchez: It's not about content.
Steven Pemberton: "not methods other than get, post, and head"
Charlie Wiecha: It's about HTTP.
Steven Pemberton: It might be of interest to some server-side XForms processors.

* XForms 1.1 Recommendation

Steven Pemberton: I have requested the transformation.

* Backplane XG Final Report


Charlie Wiecha: We are producing the final report. Please comment.
Steven Pemberton: We are proposing a WG to create an architecture for implementing XML using JavaScript.
Leigh Klotz: That's something I might be able to join.
Steven Pemberton: Ample SDK uses this type of approach and shows XForms as part of their stack: http://www.amplesdk.com/reference/#/ample/overview/lifetime.xml

* TPAC Lightning Talks

Charlie Wiecha: I've proposed a talking on the Backplane.
Steven Pemberton: Who would talk about Ubiquity? John? Mark is in Australia.
Steven Pemberton: Uli is going to TPAC. And Nick. I booked my flight yesterday.

* XForms 1.1 Testimonials

Leigh Klotz: I sent the Xerox testimonial to Steven and John.

* Future Features

** JSON Submission

Steven Pemberton: Is Kenneth here to talk about JSON submission?

** Constraints between Subtrees

Steven Pemberton: How about constraints between subtrees so that if one is changes the other is changed to match?
Charlie Wiecha: It's it's on the tip of my tongue but it's a bit bigger than we can do on the phone.
Steven Pemberton: It's the biggest thing we need to do I think.
Charlie Wiecha: I hit in in spades in the backplane demo.
Steven Pemberton: I have implementation experience in this area.
Leigh Klotz: I remember you gave a demo at CWI of a system using constraints and styling.
Steven Pemberton: Yes. It used constraints for tree updates, but it could also update the presentation tree as a shadow document using the constraints.
Charlie Wiecha: That's brilliant.
Steven Pemberton: And the constraints were two-directional so you could edit the document. That fed back to the original document. I'll dig out the references.
Charlie Wiecha: And you had iteration?
Steven Pemberton: We had a schema language defining the structure of the data and its linked presentation.
Charlie Wiecha: What about multiple tasks and iteration?
Steven Pemberton: We had iteration but no selectors because it was self-selecting as the object and datatype contained the information. A datatype clock implied a clock presentation.
Charlie Wiecha: In the Backplane demo, we assumed categories were fixed but the dates were not; so a function would collapse dates into rows in multiple passes, then that would be a data model for an SVG repeater.
Steven Pemberton: We had operators for working on data structures.
Charlie Wiecha: As functions.
Steven Pemberton: We had map and reduce. We had an incremental version that updated deltas in the target tree.
Steven Pemberton: ... change elements without changing structure ...
Charlie Wiecha: My example wasn't bidirectional. I'm curious about your bidirectionality.
Steven Pemberton: All our calculation functions were defined in both directions. You could do things that don't work (y*y=x) but it if you said (y=x*z) then there was a defined way that the directionality worked. That turned out to be useful; a currency converter, for example, works both ways. In addition to arithmetic, we did it for map and reduce as well; an intern produced a report on it. You might seem closely-related XForms issues about events in the report.
Steven Pemberton: Here is the report my student wrote on map-reduce constraints: http://ftp.cwi.nl/CWIreports/AA/CS-R9262.pdf
Steven Pemberton: We called them "invariants" instead of constraints to avoid confusion with other UI terms.
Steven Pemberton: http://homepages.cwi.nl/~steven/views/

Charlie Wiecha: I'd like to spend some time on this in the FtF, even though it's not a 1.2 issue.
Steven Pemberton: Definitely not a 1.2 issue. Once you've discovered constraints, invariants, and automatic updates, you never want to go back because the system does so much for you.

** Components

Erik Bruchez: I'd like to show some of the things we have implemented.
Steven Pemberton: Remember the implementors workshop. I regret that we didn't film the Oracle demo.
Leigh Klotz: The one where they ordered a pizza on a desktop browser, added pepperoni on IM and finished the order on voice?
Steven Pemberton: Exactly, multi-modality operating on the same form.

** PicoForms Widgets

Steven Pemberton: I'll try to bring a demo.

** HTML Extensibility

Charlie Wiecha: We could discuss this.

** Optional Models

Uli Lissé: I think we should work on simplification with optional models, like optional instances.

** UI Events

Erik Bruchez: This is a long-standing issue for us. I'd be happy to explain the problems and solutions: xforms-enabled, xforms-value-changed, etc. There are problems in the way we decide to dispatch them and the way form authors can use them. They don't make much sense from the form author's perspective, and there are better ways to define them, which is what we do in our implementation, to great benefit.
Steven Pemberton: Sounds good. The original design of XForms was original research; we knew what event-based interfaces look like, because to some extent HTML is like that, but it's good to analyze what we have now and how we can improve.

** Smaller Features

Nick van: I already created pages for a set of features: XPath 2.0, dialog, node creation, and maybe event context info. I'd like to get these in a more finalized form.

** CSS and Styling

Steven Pemberton: CSS and styling is more difficult that necessary. Perhaps agreeing on a basic style sheet might be a possibility.
Leigh Klotz: Chiba has appearance attributes on repeat and group to obtain a simple form layout; you then dip into the XSLT that produces the presentation DOM to style things more generally, leaving CSS to styling leaf nodes in the XHTML+CSS browser. I think the differences in pseudo-element implementation in XForms is what causes the difficulty.
Steven Pemberton: Maybe just documenting the pseudo-element styling (classnames, etc) in the various implementations would be helpful.
Erik Bruchez: You quickly run into Internet Explorer CSS quirks. In Orbeon FormRunner we have a basic style sheet that you can start with and improve later.
Steven Pemberton: I think a basic style ought to be included, showing invalid, for example.
Erik Bruchez: CSS is non-normative for the WG, though. In Cannes, Sebastian Schnitzenbaumer suggested we use standardized classnames, but already that's an issue because some have native elements in the DOM and some don't.

** Examples

Leigh Klotz: I'd like to see, perhaps when Ubiquity is stable, some useful XForms on the open web.

** XPath 2.0

Erik Bruchez: I find it hard to avoid using XPath 2.0 in complex pages, such as regexp, tokenization, etc. I'd like to see more of these missing features standardized.
Nick van: [irc] I agree with Erik, that XPath 2.0 is a must have in a lot of cases
Erik Bruchez: Yes, Nick implemented in Chiba.
Steven Pemberton: I'm all for saying that the next version of XForms uses XPath 2.0. XForms 1.1 wasn't supposed to take this long.
Nick van: XPath 2.0 is nice, but there are other things to change: For example repeats over sequences and items instead of nodes. It's a big step forward.
Erik Bruchez: And XPath 2.0 for Ubiquity?
Erik Bruchez: Every implementation has extensions; we need to push the important ones forward.
Nick van: Yes, a 1.2 draft with most of the useful features out quickly: dialog, node creation functions, and other easy ones.

* IRC Log


* Meeting Ends