John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Mark Birbeck, WebBackplane (irc only)
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C
Uli Lissé, DreamLabs
Charlie Wiecha, IBM
http://lists.w3.org/Archives/Public/public-forms/2009May/0039.html
John Boyer: Uli?
Uli Lissé: I am working on it
and will finish tonight.
John Boyer: One test contains an absolute link to the CSS but everything else is relative, so when you use your own copy of the test suite it uses it. It's not a normative change.
John Boyer: Does anyone object to
our making occasional changes that aren't normative?
Leigh Klotz: Maybe just a public note
saying you've done it.
Steven Pemberton: Yes, if they aren't
normative.
John Boyer: Perhaps things like the
UTF-8 encoding.
Leigh Klotz: Checkin comments?
Nick van: I generate the changes
automatically from the checkin comments, so please use descriptive
comments.
John Boyer: I'll make the
relative/absolute CSS resource change.
John Boyer: The next is a
conformance issue. There are two problems. The first is in
delete nodeset="/Dates/date" at="1".
<Dates> <date>2006-12-25</date>
<date>2006-01-01</date> <Dates>
John Boyer: Then <setvalue
ev:event="xforms-delete" ref="whatgotdeleted"
value="event(deleted-nodes)/date"/>
John Boyer: The node deleted is
deleted-nodes()/date but we get back the nodes themselves, so they
don't have children named date because they are date nodes.
John Boyer: It should be
value="event(deleted-nodes)"
John Boyer: The second problem is that
it gives the wrong value; the delete action deletes the first node,
but the label gives the second node.
John Boyer: <output
ref="whatgotdeleted"><label>You should see 2006-01-01:
</label>
John Boyer: Should be
<label> ... 2006-12-25
John Boyer: So it was probably a
1-based vs. 0-based index.
Leigh Klotz: I agree.
John Boyer: Any objections? No.
Resolution 2009-06-3.1: We accept John Boyer's proposed changes to XForms 1.1 test 4.4.2.a deleted nodes.
John Boyer: The fix is to move
binding exception message into the content of the submission.
Charlie Wiecha: Sounds like a good
one.
Resolution 2009-06-3.2: We accept John Boyer's proposed changes to XForms 1.1 test 4.5.1.a4 binding exception.
John Boyer: This test should be deleted as there is no corresponding section.
Resolution 2009-06-3.3: Delete test 4.4.21.a - should be deleted because it was moved to 4.5.5.
John Boyer: I proposed not doing
this; Erik responded saying he was OK with it for XForms 1.1. There
was a joint action for Erik and Leigh to look at it.
Leigh Klotz: Erik was the one who
noticed the issue; if Erik agrees he can implement it as we all
agreed without changing the text, then I'm happy.
John Boyer: Ubiquity was assuming
the context node for the delete was the node that was being deleted
from; however, delete-nodeset could identify multiple instances, so
it's not clear which instance to dispatch the notification event
to. We changed insert and delete from a
single node to multiple nodes. insert is limited to a
single instance, but delete can delete nodes from
multiple instances, at least the way it is structured now.
John Boyer: We have a few choices: (1)
dispatch to all affected instances (2) delete only from one
instance. There are technicalities related to those
decisions.
Charlie Wiecha: What's an example of
an expression that would span instances?
John Boyer: The union operator with
instances is the only one I could think of.
John Boyer: delete
nodeset="instance(x)/x |
instance(y)/y>
John Boyer: If you don't provide the
at attribute then you delete all nodes. If you delete
from multiple instances, surely you should get the event on all;
Erik pointed this out and I agree. Right now, the last thing to do
is dispatching the event. A delete that can delete from multiple
instances must send multiple delete events. After sending the
first, the xforms-delete processing code has more work to do. But
the author can do some things during this event. You could get into
some confusing situations.
Nick van: There are other ways to get
this problem ...
John Boyer: I was concerned we might
not fully appreciate some of the difficulties with multiple events.
The prior thought on this was around "end of processing"
dispatching the single notification event.
Leigh Klotz: In that case I'd prefer,
at this point in the life of this recommendation, is to say the
behavior is undefined. It falls under the "Doc, it hurts when I do
this" category.
John Boyer: I'd agree.
Leigh Klotz: There's no use case for
it, and it's trivially convertible from a union of instances()'s to
multiple deletes, so we don't lose any functionality.
John Boyer: I agree. Is it ok if I
create the edit now and we approve it tomorrow?
Steven Pemberton: Sounds good to
me.
John Boyer: As far as I know, that
was the last issue. Are there any other issues people would like to
raise about the changes since CR?
Uli Lissé: I don't think
so.
John Boyer: I'll prepare the document
for resolution tomorrow. Can everyone be available?
Uli Lissé: I'm not available
tomorrow.
John Boyer: Are you happy with how
this last issue is being resolved?
Uli Lissé: Yes.
John Boyer: Could we get a news
item created about the Ubiquity XForms reports?
Steven Pemberton: What's the
text?
John Boyer: Fairly similar to the
other report announcements for IE7 and Firefox.
Charlie Wiecha: I can do that.
Steven Pemberton: I can do it
straightaway. http://www.w3.org/MarkUp/Forms/#news
John Boyer: We're interested in new
web applications, and in better integration of XForms into ODF so
office documents can appear on the web. Charlie has been working
using XForms as a hub to stitch together other markup
languages.
Charlie Wiecha: I'm thinking of doing
some of the ODF idea implementations as well. Is there a
question?
John Boyer: For rechartering, what
form might it take? Combine with other groups, or have Forms group
separate. There's enough work for a forms group separately. The
XHMTL2 group doesn't have a lot of members, but they do a lot of
work and produce a lot of specs. The RDFa work is going well, for
example.
Steven Pemberton: If no one else,
wants to speak...
John Boyer: Go ahead.
Steven Pemberton: Speaking as the CWI
rep, we are interested in taking this further. My hope is that,
based on our experiences with XForms (XForms 1.1 was just "rounding
off the corners") what I hope is that in the next period that we
start again in a way and take our experience and note that we've
done very many more things with XForms than we anticipated because
our design was sufficiently general, and that has made life easier
for web applications. I'd like to make the process of making forms
much easier, avoiding complications, and generalize the features
more and make it more declarative (events and actions should be
specialized).
John Boyer: Yup. Let's look much more
closely at the big-picture architecture and less at the
dot-release.
Steven Pemberton: And Charlie, the
backplane?
Charlie Wiecha: I want to know what
you are saying. Master-detail repeat without event event wiring,
for example?
Steven Pemberton: Yes. When we first
built XForms we built on XHTML forms and built a general processor
which turned it into a surprisingly good engine. However, in use,
patterns have emerged and we can do things even more
generally.
Nick van: [irc] components for
us
Charlie Wiecha: I wonder if there is
an XBL angle and components, as Nick says. Maybe we need to embed
these extensible patterns into XForms via an XBL mechanism.
Steven Pemberton: I think that's good.
"Anything you can do, I can do meta." But I still think you do the
world a favor by saying what the patterns are.
Charlie Wiecha: That takes us deeper
into the forms space; one is hard-pressed to say what's a form and
what's an application. Would your direction do both?
Steven Pemberton: Do we want to move
ahead with the form meme, or say forms are a special case of
declarative something? We aren't doing applications, as that's done
elsewhere. I'd like to take a look at the Backplane IG results and
spell out what we want to achieve.
John Boyer: Erik is another advocate
for the XRX meme, which I think is the total solution. For
LotusForms, our discussions are about business process automation.
Our customers have a BPA problem, then they need to collect
data.
Charlie Wiecha: Erik made an
interesting announcement with XBL this week. He's pushing the
envelope. I just put it on the table that it's my interest, and I
think it's an evolution of the marketplace.
John Boyer: What's the interest level
in participating in a new web-backplane group?
Steven Pemberton: CWI will join.
Nick van: ...
Uli Lissé: I like the Backplane
idea. How will that fit with XHTML2, Steven?
Steven Pemberton: It could be that
they come back again.
Uli Lissé: I would like to take
the more architectural viewpoint and get a modular framework for
web applications.
Steven Pemberton: I agree that
modularity is a very important issue. Google Wave is based on XMPP,
which is based on XHTML modularization. There really is a value for
having modularized specifications.
Leigh Klotz: So I'm hearing Charlie
and Uli want to work on frameworks and Steven wants to work on
declarative applications on the framework.
Steven Pemberton: Modularization is
necessary but not sufficient.
Leigh Klotz: I think there could be
two activities: one doing architecture and modularization and
components, informed by use cases, and the second closer to web
application developers and authors, and developing those
declarative patterns and use cases. I'd see that as an ideal split,
but having both depend on each other and chartered together.
Charlie Wiecha: I think components is
the key piece to work on for delivering runtime modularity for
forms and for reaching out to other groups.
John Boyer: Another facet is the
recognition that components and backplane are about stitching
together the client-side experience. There is also a two-tier (at
least) application that forms play within. What if I want a number
of web pages to be working together, with a large model, and step a
user through it using more than one web page. What feature gaps do
we have?
Charlie Wiecha: ...
John Boyer: ...
John Boyer: We can discuss this more
tomorrow.
John Boyer: We need to decide about
the technical topics and group direction. Which do we want to do
tomorrow?
Steven Pemberton: I want at least an
hour of fun stuff...future directions of the technology.
John Boyer: Picking a few from the
Future Features bucket?
Steven Pemberton: I haven't gotten
that far.
John Boyer: We can have some technical discussions as well and that will fuel the directions.
John Boyer: Tomorrow, we start at
7AM my time.
Steven Pemberton: Two hours earlier
than this.
John Boyer: And we talked about 2
hours, a break.
Leigh Klotz: I'll be out at 8:45 my
time for a bit.
John Boyer: We'll use Yugma. Then we
can talk for an hour on future directions, then future features
Wiki, then break, then deeper dive on high-priority issues. And
XForms 1.1 PR.