Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Kenneth Sklander, PicoForms
David Landwehr, PicoForms
Leigh Klotz, Xerox (minutes, late)
Mark Birbeck [irc], webBackplane
Steven Pemberton, CWI/W3C
Uli Lissé, DreamLabs
http://lists.w3.org/Archives/Public/public-forms/2009Jun/0012.html
John Boyer: [Scribing in the IRC
log for this agenda item]
Kenneth Sklander: Some of the best
features of XForms 1.1 Targeted submission, and copying nodes with
insertion (not that we like the word insert) More detailed
submission element (i.e. the additional attributes) good cleanup
from 1.0 Spec rewrite in itself was a good feature of 1.1. Cleaned
up a lot of ambiguities From 1.2, JSON submissions are important
>From 1.2, don't remember the other things we implemented offhand
but the list coming up on the coming agenda looks very good
John Boyer: [See IRC Log.]
Kenneth Sklander: From 1.2, JSON
submissions are important
Kenneth Sklander: From 1.2, don't
remember the other things we implemented offhand but the list
coming up on the coming agenda looks very good
John Boyer: Kenneth, can you comment on the future goals that you have implemented and other ideas? http://www.w3.org/MarkUp/Forms/wiki/Future_Goals
Action 2009-06-10.1: Kenneth Sklander to provide list of implemented future features and other new ideas.
Steven Pemberton: I need to include
a list of important changes since last call.
John Boyer: All we have are the
diffs.
Steven Pemberton: Are the diffs
against the last-call version?
John Boyer: That would be agains the
CR version.
Steven Pemberton: Yes, that version; I
was mixing up the transition. So I can create the list and say to
see the diff document.
John Boyer: The diffs are both
important and unimportant.
Steven Pemberton: I can do the work to
produce the diff of major changes. The diff document doesn't say
it's a diff against the CR version. Could you add a link to the
version it's relative to?
John Boyer: It's always a diff against
the last published version.
Steven Pemberton: OK.
John Boyer: There are 436
diff-marks.
Action 2009-06-10.2: Steven Pemberton to summarize major differences between CR and PR.
Steven Pemberton: And I need a
Disposition of Comments.
Charlie Wiecha: These aren't last-call
comments, as this is after last call.
Steven Pemberton: Changes made against
comments.
John Boyer: Brutal.
Steven Pemberton: I'm only really
interested in comments sent to the public list; comments from
within the working group not sent to the editor list need not be
reflected in the Disposition of Comments. That is to make sure we
did not reject any of them; we must explain those in the transition
call.
John Boyer: That's in the mail
archive.
Steven Pemberton: I will start off
making a document listing the issues sent to the comments list.
Action 2009-06-10.3: Steven Pemberton to make initial draft of Disposition of Comments document from www-forms-editor list.
Steven Pemberton: I'll categorize them as editorial or substantial and what we decided to do with it.
John Boyer: Aaron Reed, the Mozilla
XForms Extension implementor, asks when the events happen. I would
think as part of default processing. Are there others who do the
delay queue for the dispatch action.
Kenneth Sklander: We have a
queue.
John Boyer: When do you get rid of
it.
Kenneth Sklander: It depends on the
event; some at the next UI. I can make a matrix.
Action 2009-06-10.4: Kenneth Sklander to provide implementation comments on when to flush event queue for dispatch with delay.
John Boyer: So when does the queue
of unexecuted futured dispatches actually happen?
Default-processing of model-destruct? I think the concern is that
if you don't say when the queue goes away, it's possible the
implementation might do a dispatch after processing is over with. I
didn't feel we need to specify this in such detail; it seemed to me
that model-destruct is notification that the model is going away
very shortly.
Kenneth Sklander: It's a good point as
there are multiple models and not every event is model.
John Boyer: Everything in XForms is
either the model or associated with a model. There may be a few
exceptions to that for things that have optional UI bindings, but
even thenm I'd associate them with the model of their context
node.
Kenneth Sklander: The error event that
you cannot find the model id is not associated with a model.
John Boyer: There's no processing for
destroying only one model.
Leigh Klotz: We might transclude
models or use show=embed, so I wouldn't want to make a decision now
that precludes that.
John Boyer: So in that case we'd have
to remove items associated with those models from the queue. Every
dispatch would have to have an associated model.
Kenneth Sklander: In our experience,
it's complex. We have to enter the queue with different fields at
different times. There could be UI elements with relevance and the
UI disappears. Maybe we can make a matrix that says when this event
occurs, that disappears from the queue, and also answer Aaron's
question.
John Boyer: So if the element doesn't
exist any more by the time you dispatch?
Kenneth Sklander: Maybe the element
exists but cannot do what it wants to do.
John Boyer: Can you list it?
John Boyer: There's a case element child of switch which acts like a group, and one of toggle, which computes. He found it confusing, because there's no forward link from one case element to the other, to help the reader understand. >From an editorial perspective, we can make a forward link.
Action 2009-06-10.5: John Boyer to provide
informative links between the two case elements in
XForms 1.1.
John Boyer: It also looks like the
schema is incorrect; it was added as a local element of the toggle,
but set up by reference and referenced the other case element, the
one that is intended to be a child of switch. We need to fix that.
I'm game to fix that live here on the phone. It ought to be defined
locally.
Leigh Klotz: When we started out all
elements were global and we never really changed it.
John Boyer: There's good reason to fix
it now. Can I just put the element definition inside?
John: <xsd:sequence maxOccurs="unbounded"> <xsd:element ref="xforms:case"/>
<xsd:element name="case">
. So it's already locally defined and ther's nothing wrong with the Schema at all. My apologies.
John Boyer: I must have made a mistake; the schema appears to be right. The toggle element has a sequence <xsd:element name="case" type="xforms:ValueTemplate"/>
Leigh Klotz: Markus Gyllig has
implied he would help finish the RNG schema in a few hours if we
needed to publish it.
John Boyer: The XSD Schema is a
non-normative reference now.
Steven Pemberton: Or publish it as a
note, and correct it as we need.
John Boyer: Or publish it next to the
XSD Schema location and put it in the non-normative section.
Steven Pemberton: I have no objection
to that if it's non-normative.
John Boyer: So we can do that any time
before REC.
Leigh Klotz: So it's equal status to
the XSD Schema, being non-normative.
John Boyer: Yes.
Leigh Klotz: OK, I'll ask Markus if
he'll finish it before we go to REC, and if he does we can publish
it in XForms 1.1 REC as equal status to the XSD Schema, which is to
say, equally non-normative.
John Boyer: Yes.
Leigh Klotz: One more point: are the
simpleTypes (the xsd:integer union empty string, for example) in a
separate file?
John Boyer: No.
Leigh Klotz: It might be nice to pull
them out.
John Boyer: OK, if it's necessary.
Action 2009-06-10.6: Leigh Klotz to Markus Gylling if he'll finish the XForms 1.1 RNG schema before we go to REC, and if he does we can publish it in XForms 1.1 REC as equal status to the XSD Schema, which is to say, equally non-normative.
John Boyer: Vlad's confusion is
that submission has a lot of attributes. I think he's not reading
the rest. Is anyone else confused?
Leigh Klotz: Do you know what
editorial change you want to make?
John Boyer: Not really; I know in
general, but it's quite a bit of work. It could be narrowed to
xforms submit default processing section and one other
section.
Leigh Klotz: Well, if it's only
editorial, then perhaps it could be resolved simply with a note
saying that there are definitions in different section.
John Boyer: Vlad said there he only
read the attribute definitions and didn't realize there was another
section.
Leigh Klotz: You could add a note
saying to read the other section, and that would be a response, but
it's not clear doing a lot of work is necessary.
John Boyer: If someone else hits it in
the future we can consider it.
Steven Pemberton: [irc] I have made a first version of the XForms 1.1 DoC at http://www.w3.org/MarkUp/Forms/2009/xforms11-PR-DoC.html
John Boyer: I summarized our
discussion in the Future Goals section of our wiki. http://www.w3.org/MarkUp/Forms/wiki/Future_Goals
John Boyer: The Backplane concepts is
only a subset of the WG interests. We have other areas of
interest.
Charlie Wiecha: Aggregate apps,
broader client concepts.
Steven Pemberton: So XForms is only
part of what the Backplane is trying to achieve?
John Boyer: No, there are other themes
in the WG that are Forms work. The most important discussion for
the current WG is whether there is a willingness to recharter this
group. There seems to be a lot of work for the Forms WG to do.
Could we recharter under a new name?
Charlie Wiecha: Are the aggregate apps
and broader client concepts interesting for the current
community?
John Boyer: We have a community that
is interested in "content-intensive applications." That's what
we've meant for a long time with "form," dynamically-responsive
applications. A group of pages working together, or users working
together to create content with a server-side process orchestrating
what's going on across a number of pages; yet still to get from
page-to-page in that scenario there are things we can do to improve
XForms. There are efficiency problems calling things in a sequence.
We don't have a way to address web server security.
Charlie Wiecha: On aggregate
applications, are we saying that the complete mechanism would be in
scope, or just the deltas to the forms functionality with the
architecture defined elsewhere.
John Boyer: I think the second. There
are people who are doing commercial products doing workflows and
business process, and I happen to be one of them. There are aspects
of XForms now that we can't use beceause they are too
coarse-grained and make the assumption that the web page is the
application with one user.
Charlie Wiecha: I see nowhere that
that assumption is being relaxed, except for widget packaging. Is
that in scope, the intearctive scope of artifacts and
resources?
John Boyer: It depends on what define
as a form. We'd have to make improvements to XForms either
way.
Erik Bruchez: It depends on the size
of the group. There's so much to do with incremental XForms
improvements that it's going to be hard to do them all. With
orchestration and composite applications, there's a risk that we
can sit around and try to make things up with limited usefulness.
As far as I'm concerned, it's better to focus. It's great to
introduce new ideas but the core for me is to standardize what
people have been doing, and work on improvements to XForms as it is
today.
Charlie Wiecha: It is a standards
group, not a research group. That's an important point.
John Boyer: It might give us some
focus.
Erik Bruchez: I don't think the
members would be much different from what it is today.
John Boyer: There seems to be a lot of
progress we can make as the Forms WG.
Leigh Klotz: Could the backplane work
be done in XHTML2 if we have a forms focus?
Charlie Wiecha: The issue is more on
aggregate apps and other things.
John Boyer: Authoring issues. I've
called out concentrations of ideas that aren't 100% orthogonal to
one another. One thing would be tagged as a Backplane feature, an
authoring extensibility feature. Custom xpath functions, custom UI
components (which goes into Backplane). Fair?
Charlie Wiecha: Absolutely.
John Boyer: A better DOM interface
(which depends on what better means) bleeds over into client
context, and backplane.
Leigh Klotz: So would this fit well if
we had a forms focus?
John Boyer: Yes, what we've always
thought of as forms.
Charlie Wiecha: The renaming issue was
to get the rest of the world to understand that. Rechartering as
forms is OK though.
John Boyer: Is it possible to
recharter the group and change the name?
Erik Bruchez: The release of new
Microsoft Bing is interesting...they plan to spend $100 million on
marketing. Some people ask if it's better to spend that on making
it better. I don't know if renaming the Forms WG would help much. I
think Ubiquity XForms maturing would be one of the best ways to
spread out.
Charlie Wiecha: I feel people get hung
up on the name forms.
John Boyer: I think even if we hadan
alternative name, there are groups whose names...
Charlie Wiecha: I'm not sure we have
to change name, but we have to get across that the technology is
beyond forms.
Erik Bruchez: I think there are
exciting things to be done. I like extensibility and XBL and custom
UI components. Very practically, you can pull in and leverage
existing JavaScript frameworks. We have had demos of this (maps)
but it's not been a main focus. I believe there's a chance of
showing it's not just about input fields by putting in the right
features.
Charlie Wiecha: I presented that idea
but there was a lack of support for XBL. That was my preferred
proposal for Ubiquity but there are issues around it.
Erik Bruchez: Ubiquity is implementing
without native support for XForms. We implement it on the server.
Google GWT is used for Google Wave, and it's all written in Java
and turns into HTML+JavaScript in the browser. We can do the same
with XForms. Even if XBL isn't in the browser, it's not a major
obstacle.
Charlie Wiecha: Exactly those issues.
Adaptations of our technology as a bridge is precisely the kind of
thing we should be discussing. At least some effort on
consumability needs to go forward. We can do features along the
way.
Erik Bruchez: I do not disagree but I
don't know how the W3C can do this work as it's not a marketing
organization. There are many ways to implement. It seems more
Ubiquity.
Charlie Wiecha: That's the argument
Leigh's been making about the Ubiquity Benevolence Society.
Leigh Klotz: I think it needs to
exist.
John Boyer: It would help to know if
we can change the name, and if people are interested.
John Boyer: As I started to put
these things into themes, I see we are starting to talk about
broad-strokes future requirements. When should we go out to
www-forms and other lists and try to drum up possible interested
members?
Leigh Klotz: We should have something
concrete that might appeal, not asking for suggestions about what
we ought to do.
John Boyer: Tomorrow, then.