Mark Birbeck, x-port.net [IRC]
Charlie Wiecha, IBM
David Landwehr, PicoForms
John Boyer, IBM (chair)
Joern Turner, Dreamlabs
Leigh Klotz, Xerox (minutes)
Lars Opperman, Sun
Nick van den Bleeken, Inventive Designers
Rafael Bonito, SATEC
Roger Perez, SATEC
Sebastian Schnitzenbaumer, Dreamlabs
Steven Pemberton, CWI/W3C
Erik Bruchez, Orbeon
Susan Borgrink, Progeny
Keith Wells, IBM
John Boyer: Jan Kratky, who is departing the group for IBM Rational products, said that the XForms 1.1 Schemas aren't finished yet.
Action 2007-06-6.1: Mark Birbeck to update XForms 1.1 Schemas.
John Boyer: The patent policy is up
to date. There is no disclosure required. The only step before PER
is that we don't yet have an XForms 1.0 TE test suite.
Keith Wells: I've updated the CVS tree
with a TE test suite and sent a note to Steven to update the link
on the internal WG page in the last hour.
John Boyer: Does it have any
additional tests that reflect errata for the third edition?
Keith Wells: It does SE but I assume
it matches TE. I believe we're up to date with TE.
John Boyer: The TE now includes
published errata for SE?
Keith Wells: Yes.
John Boyer: And this includes the
link?
Leigh Klotz: Does this include the
link to update XForms Basic tests?
Keith Wells: Yes.
Leigh Klotz: Good.
Leigh Klotz: We need to finish the
implement the update report, send it off to PicoForms for testing,
and fix the confusing sentences in Conformance that led Jan to
think that leaving out XML Schema was conformant.
John Boyer: We just want to exclude
implementing full schema? Send me the sentence and I'll fix
it.
Leigh Klotz: No, that's not it,
because implementing on XML Events Basic also makes it XForms
Basic. We just want to prohibit implementing no Schema.
Nick van: [IRC] should implement
subset may implement the whole
John Boyer: OK. It's not a problem to
update the sentence.
Action 2007-06-6.2: Leigh to update confusing Schema profile sentences for editorial update.
John Boyer: We don't want to do a
3-day thing. The Sunday isn't attractive either. But Dave Megginson
also points out they have some evening events; December 3rd or 4th.
There could also be XForms Tutorials or Overviews. Any of those
options would still associate us with the conference.
Sebastian Schnitzenbaumer: I like the
evening event option 2. At the end of the conference, people are
tired. It's nice and informal, and a good start.
John Boyer: OK. The other thing he
said is that XForms papers are also welcome in the main program;
they have a web enterprise track. We can get XForms papers into the
regular conference as well. Good point about December 5th.
Sebastian Schnitzenbaumer: We have our
own evening then. It's not a big thing but it's still something to
feel good about. I'm sure it will be over-run. I'd ask for the
Tuesday evening. Monday would be fine too, but Tuesday would be
perfect.
John Boyer: OK, I'll ask for Tuesday,
December 4th. I wonder, should we ask for an activity on both
nights?
Steven Pemberton: [IRC] Yes! I have an
objection. (I have to be in NL on Dec 5.)
John Boyer: OK, Monday Dec. 3
then.
Sebastian Schnitzenbaumer: OK.
John Boyer: OK, we go with Monday
then.
Resolution 2007-06-6.1: We go with Monday Dec. 3rd for the XForms Evening at the XML Conference
John Boyer: Does moving this to
member-only HCG even make sense? Join questionnaire needed?
Sebastian Schnitzenbaumer: It's a pure
process issue; the mailing list and number of members (3 from each
group perhaps) could be decided there. If it's not a good idea, ok,
but if we want to fulfill the charter, then I think this is the
only way to get it created.
John Boyer: That's a good point. I'll
go onto the call on Friday and explain it to the HCG. There are
400-odd people; as many people signed up to have interest as we
have in our WG.
Sebastian Schnitzenbaumer: It's not
about being outnumbered; it's about having a technical discussion,
not about convincing. I'm following the HTML WG.
Erik Bruchez: I cannot attend the
F2F. During technical issues, I could attend part of
Wednesday.
John Boyer: Yes, good point to bring
up the F2F. I'm hoping that we'll be heavy on resolving last-call
issues. I've been trying to think of a way to organize the work so
that actually happens. Take the people who showed up, cut them into
two-man [sic] teams, and go over the emails for last-call comments,
to split them up into last-call system, what to say, that sort of
thing. I just want to throw that out there and how about we do
that. A work-bee on last-call issues?
Leigh Klotz: We did this for the
Halloween F2F at Netscape in San Diego for the test suite. Was that
a F2F?
John Boyer: Yes, it was a F2F.
Leigh Klotz: So there's
precedent.
John Boyer: I'll float around and try
to help get answers. The best is to reach agreement. Otherwise I
don't see how we can get through last-call issues.
Sebastian Schnitzenbaumer: The group
was bigger and we had more people; we brute-forced through it. We
had a 3-day F2F. It took a year or so. We used Shane's system. The
disposition of comments was helpful as well. Talking to people
directly helped as well. By the time of the official last call
comment, it was all done. We had over 150 comments. In retrospect,
I'm glad it's happened.
Erik Bruchez: Where do we stop?
Sometime in April? What about the ones after?
John Boyer: The language of the
last-call period says is that issues that arrive after that have
the possibility of being considered, but if it gets out of hand,
then no. It looked like a lot of the feedback that showed up in May
was good. I'd still want to address it.
Erik Bruchez: All right.
Sebastian Schnitzenbaumer: This is a
bit radical, but I have an idea. Realistically, I would use every
single second at the F2F for last call and put every issue on
overhead and walk through as an entire group and close the issues
and deal with them there. I think that's the most realistic; people
are focused and there is no distraction. Working with just two
people would just be distracting.
John Boyer: I'm amenable to working on
only last call.
Leigh Klotz: John did you mean just
two people or everyone in two-person groups.
John Boyer: Everyone, n/2
groups.
Sebastian Schnitzenbaumer: I think
everyone is the way to move forward, and no other issues.
John Boyer: We've done that with
errata.
Sebastian Schnitzenbaumer: Uli, who is
taking over the issue database, will be there at this F2F.
John Boyer: We'll try it this way
you're talking about Sebastian, and try it for at least Wednesday.
If we somehow rathole and don't make it through many then we may
have to rethink it. I'm concerned if we don't do something other
than everyone, we'll get to the end of the F2F we won't be done.
There are quite a few emails.
Nick van: [IRC] and some contain
dozens of different comments
Sebastian Schnitzenbaumer: As chair
you'll have to be snappy and sharp. There's a lot of things where
you can get involved. If it's just implementation details and
discussing in the spec, then just go for some solution, make a
resolution, and go on.
John Boyer: Let's dissect a comment.
As Nick said, some have a dozen issues, and some are [editorial].
Surely it seems that we need to decide about fully dealing. Does
that include changing the spec?
Sebastian Schnitzenbaumer: I think so,
yes.
John Boyer: Some of those will be
highly un-entertaining.
Sebastian Schnitzenbaumer: Yes, it
won't be fun, but do we then postpone it? You could have someone
work on the spec. Don't work on the issue tracking system; just use
a bullet list. And get the list down so that we can do them on the
teleconference.
John Boyer: Sounds like a plan.
John Boyer: On Erik's question;
Erik you have a body of unique issues. I realize you can't be at
the meeting, but the bulk of issues for insert and delete, could
you work on those during the F2F Week?
Erik Bruchez: I will be on the West
Cost of the US on Wednesday. On Thursday and Friday I will be
travelling. Unless the group decides there is something wrong, I
believe we should conclude my changes and decide as a group whether
to accept or reject it.
John Boyer: Take the source bundle on
the airplane, assume it's a "go," and make the spec-changes with
diff marks on the airplane and discuss it afterward.
Erik Bruchez: Are the diff marks
new?
John Boyer: Yes, take the editor's
draft off the public page and start from there. It's safe to add
diff marks.
Action 2007-06-6.3: Erik Bruchez to update http://www.w3.org/MarkUp/Forms/specs/XForms1.1/xforms11.full.zip with diff-marked insert changes.
John Boyer: Just assign it to me.
Action 2007-06-6.4: John Boyer to handle http://lists.w3.org/Archives/Public/public-forms/2007Jun/0008.html
John Boyer: I'd forgotten Joern was
assigned this. He produced a result this morning.
Erik Bruchez: I was responding. I'm
not sure I can agree with that change because I don't understand
what it means. I can summarize Joern's updates to the spec to say
that if a node can be changed with setvalue and calculate, it can
also be changed with instance replacement. So a node replace with
instance replacement would be marked with xforms-value-changed. I'm
not sure I understand; when an instance is replaced, every single
node is replaced. Every single node is replaced. So every single
node in that instance is new. So I'd like to understand if this
means that you'd create a new XML document and mark every node as
requiring xforms-value-changed to be dispatched. I'm not against
that; it's what we currently do in our implementation. It's a
brute-force way of dealing with instance replacement. Every single
node has changed, but the value may not have changed.
John Boyer: Yes, that would be my
interpretation too.
Joern Turner: Yes, that's how I meant
it. I thought a lot about it. I see the problem that it's
potentially not very efficient, but I don't see a better solution.
I'm not totally happy with that change. Without inventing a new
event or changing the spec in a more heavyweight way I don't see
how we can solve this.
Erik Bruchez: This to me looks like an
unfortunate consequence about value-changed. I would imagine a
control is bound to the node, and it gets the value of the node,
and it does a refresh, and it gets the new value.
Nick van: [IRC] wil it also send the
read-only/read-write valid/invalid, .. events?
John Boyer: [IRC] yes
Erik Bruchez: Instead we have this
awkward method of marking nodes for value-changed. It may bind to a
different node, but have the same leaf value, and still get value
changed. We if handled refresh this other way, then it would
work.
John Boyer: That would be ideal but
then the model would have to ask the control what the old value
was.
Erik Bruchez: The idea would be the
control stores its value, and if there is a setvalue, then it would
save its old value.
John Boyer: When you replace the
instance, the new lexical value may be the same as the old one. The
fact that the new one is lexicographically equal to the old one is
a coincidence.
Erik Bruchez: I think it's just very
confusing.
John Boyer: Suppose you have an XForms
control with a UI binding that has a predicate. If something about
the predicate changes so it binds to node b instead of
node a and they happen to have the same value, then we
say that the ui control will receive xforms-value-changed and the
MIP events.
Erik Bruchez: Where do we say this?
You say if the binding changes we dispatch? We do this when we
switch the control from non-relevant to relevant but I don't think
we do this on binding changes. My understanding is that we can have
a binding change and get a different value and not get
xforms-value-changed.
John Boyer: If the spec doesn't say
that then we have another problem. My understanding of UI
re-rewiring is that it should trigger value-changed. I think the
root cause of out problems is that bullet point 2 is too
restrictive. It should list examples. If a control changes node it
should get the full range of MIP events.
Erik Bruchez: You can do xforms delete
followed by insert of a new tree; that's very similar to instance
replacement. It wouldn't prevent the case where we send the event
and the value hasn't changed. If you ask me, storing the old value
in the control would be better, between refreshes. Then the
description of the algorithm would be a one-liner. Yes, or
no.
John Boyer: You get into the issue of
equality; we could use the XPath equality.
Leigh Klotz: The leaf node.
John Boyer: String equality.
Leigh Klotz: I thought you meant the
path.
John Boyer: With Erik's proposal UI
controls would hold their old value.
Leigh Klotz: Do we put the old value
in the context info of the xforms-value-changed?
John Boyer: No
Erik Bruchez: We do that.
Leigh Klotz: It sounds like John is
saying the model needs to query the control, and Erik is saying
that the UI control would decide it itself.
Erik Bruchez: I think ...
John Boyer: We are out of time; let's
pick this back up on the list. Asking the control to keep the old
value is too big for 1.1. Let's just fix it so that 1.1 says what
the implementations do.
Erik Bruchez: In that case, we need to
fix it for insert.
John Boyer: Let's pick it up on the
list. I think it's more like UI construct.