Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (Chair)
Kenneth Sklander, PicoForms
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Roger Pérez, SATEC
Uli Lissé, Dreamlabs
Keith Wells, IBM
Paul Butcher, WebBackplane [joined late]
Charlie Wiecha: I'd like to
de-brief on Wednesday in general, both TPAC and Plenary. On the
Backplane, TV Raman I met with the Multi-Modal group. We started
with the Ubiquity implementation. There was some discussion for
JavaScript tag libraries for Voice XML; speech and search are
native, but the semantics of the markup could be factored away.
There were interested in this this approach, and have had similar
platform issues.
Charlie Wiecha: Then we did demos of
the data model from the backplane group, for cross-component
coordination. We showed a mortgage-wizard spreadsheet in ODF
rendered using a Dojo grid control. The spreadsheet total is the
passed to XForms via a JavaScript setvalue function from the ODF
side. The form refreshes and recalculates implicitly. They didn't
see why that was multimodal, but I explained it was
cross-component, which is the same.
Charlie Wiecha: Then we showed it with
a Voice XML form using DOMFocusIn using Chris Cross's voice prompt
extension for fields. It doesn't do the wizard from ODF but it's a
modality assist. That also does a setvalue back into the data
model, which does an update. Unlike earlier multi-modal proposals
(such as X+V) which were control-to-control wiring and local
interaction, this goes to the data model and synchronizes
value-spaces. They liked the deeper-level connection.
Charlie Wiecha: Rahul from our team
then talked about using the data model in Voice XML 3.0. There is
nobody from Voice or Multi-Modal on the XG yet.
Charlie Wiecha: Dave Raggett has an XG
called the Layered UI. At the low level it fits with XForms. There
has been academic work in the past decade on layers above it, task
modelling and business processes. I gave a presentation on how to
connect their academic work to XForms. One presentation they did
was connected. I don't think W3C is a good place to do modelling
layer specifications, though, and I said that.
John Boyer: Modelling only is not
something that the W3C is very receptive to.
Charlie Wiecha: I think it's an uphill
battle for Dave. There's a big gap around rich internet apps. I
don't think he's ready to tackle the area around it.
John Boyer: They need to have the
mental model available so they can do it at runtime.
Leigh Klotz: I'm interested in a
related topic, which is to replace the XSLT level of Chiba with
Freemarker or PHP and allow web designers to design the whole
system in the markup, including XBL-like behavior and decoration of
elements based on type and appearance, with the XForms model
driving the data and the existing underlying machinery handling the
dynamic updates. The same XForms markup could be static, or
dynamic, and could bottom out in glass or in server-side templates
(which could be recursively be more templates or more XForms, or
just glass). This may have been what Joern Turner had in mind years
ago, and I'm just catching up. But I think that XSLT isn't the
right language for designers; we're ignoring this design-time
process you mention, and bringing something more fluid and
understandable such as Freemarker might help. Ubiquity draws the
line and keeps it all on the client; I'm proposing a different
approach to consider the templating process and integrate with it,
allowing the same expressions to be used in both static and dynamic
expressions.
Charlie Wiecha: It's an interesting
idea that ties to Wednesday's discussion.
Charlie Wiecha: We had lots of
informal discussions and it was exciting.
John Boyer: I'm sorry I couldn't be
there.
Charlie Wiecha: We talked about the
end-run strategy. TBL and Chris Lily jumped to the microphone and
asked if this would be a great way to get out of the stagnation
we're in. There were some questions about namespaces, but that
didn't go anywhere. The pushback was just that once we get MathML
and SVG done we have no more need of markup. I pointed out that ODF
and other languages were quite interesting. I think we made the
point there are other vocabularies and we don't want to go through
a single choke-point. The discussion was mostly about using
Ubiquity as a tag library. The session went through the break and
used some of W3C foundation time from Steve Bratt, so we got
another half-hour because the discussion was going around script
libraries as a continuum between base browser and markup. Chris
went around and told the browser vendors to make a commitment to
support this kind of extension technology, and XBL. They all said
it was on their agenda.
John Boyer: That's great. So a
specific message to Steve Bratt and TBL, for our
rechartering.
Charlie Wiecha: If we can get someone
(perhaps Chris) to own the tag library extensibility, that would be
great.
Nick van: I had a meeting with one
of the chairs, and he felt we needed to work find a way to work
together. I sent email to follow up but haven't gotten anything
back yet.
John Boyer: Worst-case is that we
finishing it alone as a first public WD. If we then build it in
Ubiquity, we can (as Leigh said) get support of multiple
implementations of a browser-by-browser basis with Forms-A, such as
in Internet Explorer. We don't just be talking about it; we'll be
doing it across browsers. We can then set a timeframe for the
cross-WG interaction, but eventually go to last call. If we then
get it past CR, then we're have interoperating
implementations.
Charlie Wiecha: Is it one
implementation?
John Boyer: Leigh's point, and I think
he's right, is that there are separate codestreams that get
integrated to run in the various browsers.
Leigh Klotz: Write once, run anywhere?
Anyway, I think getting the disablers removed the value we could
get, by getting Chris to go back to the browser vendors to get them
to leave XML (both data islands and host markup) alone.
Charlie Wiecha: It would be good to
inventory these.
John Boyer: Another good thing to
do would be the take the "X" out, next year, and deal with JSON for
example.
Charlie Wiecha: One of the XG folks I
mentioned claims to be doing that.
John Boyer: That would be good to get
done.
Charlie Wiecha: A fair chunk of FormsA
is already in. I keep sending links.
John Boyer: It can be a good
response to Ian's message. Instead of asking for declarative
features, just describe the value. Otherwise, people get asked if
they want a "gazorninplat" and will say no. Consider the purchase
order: ask one question such as, do you want it to be this easy to
add a row to a table, or to provide an ever-present sum? A big part
of Ian's response was that he was looking at Dave Raggett's proposal,
where the calculate attribute runs JavaScript, where you can't
figure out the dependencies, or if you don't, "there's no language
worth the trouble."
John Boyer: I don't think the average
web developer needs to go very far to understand to use slashes.
But we need a response. And we need a bigger forms example.
Leigh Klotz: We need a series of
smaller examples.
John Boyer: We need to finish PO in
FormsA, but we can't just show X+Y toys.
Leigh Klotz: An example of all
simplified syntax would be different in so many places it wouldn't
be a good introduction. I'll do an example of what I mean, showing
how to do one or two things at a time and you can do it in
FormsA.
John Boyer: Please send me the 1.0
Basic implementation report.
Leigh Klotz: OK.
John Boyer: It's pretty solid so far; changing to another solid representation will be easy.
John Boyer: This attribute indicates that the element is a form, but some host languages might use an element, perhaps named form. You can have multiple ones per document. The form is the site of an implicit XForms model, which you can declare.
Charlie Wiecha: What's the use case
for nesting of forms (not models)?
John Boyer: You have to separate
contained forms and container forms, and we don't need two
types.
Charlie Wiecha: We don't have subforms
today. I see the need for having the whole form be one, implicitly
at the root. Implicit nested model rules seem complicated.
Nick van: [irc] can't it just replace
the implicit one, just like we do with instance?
John Boyer: Does anyone object to the
restriction that you can't put forms within forms?
Charlie Wiecha: And the implicit
document root. Error, or ignored.
Nick van: [irc] no, that is something
of scope for XForms 2.0
John Boyer: Ignored. And as Nick says
we can deal with nesting later.
John Boyer: So as soon as you use a
form attribute in a contained location, forms outside that location
stop working.
Charlie Wiecha: You'll have to
introduce new form attributes.
Leigh Klotz: So if you have input,
div, input, and the I add the form attribute to the div you can't
have the inputs with a separate form.
John Boyer: HTML4 can't do that. This
is the same model but not necessarily the same data.
Action 2008-10-29.1: John Boyer to remove nesting capability for form attribute in http://www.w3.org/MarkUp/Forms/specs/XForms1.2/modules/streamlined/index-all.html#form-containment
John Boyer: Next is creation of
instance data. There's the name attribute binding a form control
and creating data. We have some fancy dancing with inputs with the
same name.
Leigh Klotz: You can also have inputs
with the same name, which is how repeat is done.
John Boyer: We achieve repetition by
some other means. That's an interesting hurdle. So don't repeat
things by using different input tags, but by a startsize attribute.
Then increase or decrease the number of those things that you have.
radios and checkboxes would be a legitimate use; see type. To
initialize the data, we had to have a way to specially indicate
certain of the controls bound to the same piece of data. In the
case of radios and checkboxes, there's a different algorithm needed
to initialize to a starting value.
Charlie Wiecha: Do we have a story
for non-XML submission in FormsA? There still needs to be a way to
do submission.
John Boyer: The primer will start out
showing this issue. The serialization attribute will default to
application/x-www-url-formencoded.
Charlie Wiecha: So an XML instance at
runtime doesn't mean that it must be serialized that way.
John Boyer: We already have an
algorithm for it.
Leigh Klotz: So are you going to put
in JSON serialization?
John Boyer: I'd like to.
Leigh Klotz: Let's just put in a
section for it and a reference and invite comment.
Action 2008-10-29.2: Leigh Klotz to provide reference for JSON serialization for FormsA.
Charlie Wiecha: We may need some
serialization for implied model with the value. We need to say how
to get access to the value.
Leigh Klotz: Right now you do
document.getElementById(foo).value which I don't think
is the same as the value of the attribute of the element whose ID
is foo.
John Boyer: That reminds me we need a
setter for markup.
Charlie Wiecha: And a getter.
John Boyer: Maybe get and set. They
can define the effect on .value if they want.
Charlie Wiecha: Up to the host
language.
John Boyer: I'm happier if we don't
mess with host language attributes, but as Leigh points out it's
not the same as the .value.
Charlie Wiecha: It's the runtime, that
indirects into the instance.
Action 2008-10-29.3: John Boyer to put into FormsA a getter and setter for form controls.
John Boyer: My goal if first public working draft on this document.