Erik Bruchez, Orbeon
Steven Pemberton CWI/W3C (Chair)
Uli Lissé, DreamLab
Charlie Wiecha, IBM
Leigh Klotz, Xerox
Nick van den Bleeken, Inventive Designers
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.
Steven Pemberton: I have requested the transformation.
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
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.
Leigh Klotz: I sent the Xerox testimonial to Steven and John.
Steven Pemberton: Is Kenneth here to talk about JSON submission?
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.
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.
Steven Pemberton: I'll try to bring a demo.
Charlie Wiecha: We could discuss this.
Uli Lissé: I think we should work on simplification with optional models, like optional instances.
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.
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.
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.
Leigh Klotz: I'd like to see, perhaps when Ubiquity is stable, some useful XForms on the open web.
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.