Re: Draft Minutes June 6, 2007

Thanks, Leigh.

I have one minor correction, under F2F I am recorded to have said:
"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."

Whereas what I really meant was, and maybe it didn't even get clear enough
on the call itself:
"Sebastian Schnitzenbaumer: Yes, it won't be fun, but do we then 
postpone it? You could have someone work on the spec. If working on the 
issue tracking system at the F2F slows the group down; just use a bullet 
list; and update the issue tracking system later, after the F2F."

(Just to avoid being interpreted as discouraging people to use the Issue 
Tracking System)

- Sebastian

Klotz, Leigh schrieb:
>
>
>   W3C Forms teleconference June 6, 2007
>
>
>     * <#topic0> Present
>
>     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
>
>
>     * <#topic1> Agenda
>
> http://lists.w3.org/Archives/Public/public-forms/2007Jun/0014.html
>
>     * Previous Minutes <#topic2>
>     * XForms 1.1. Schema <#topic3>
>     * XForms 1.0 Third Edition <#topic4>
>     * XForms Basic 1.0, 1.1 <#topic5>
>     * XForms at XML Conference <#topic6>
>     * Forms Joint Task Force with HTML WG <#topic7>
>     * F2F <#topic8>
>     * Editor action item <#topic9>
>     * Instance replacement fix needed <#topic10>
>     * IRC Minutes <#topic11>
>     * Meeting Ends <#topic12>
>
>
>     * <#topic2> Previous Minutes
>
> IRC supplement: http://www.w3.org/2007/05/30-forms-minutes.html
>
>
>     * <#topic3> XForms 1.1. Schema
>
> 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: <#ACTION1> Mark Birbeck to update XForms 1.1 Schemas.
>
>
>     * <#topic4> XForms 1.0 Third Edition
>
> http://lists.w3.org/Archives/Public/public-forms/2007Jun/0013.html
>
> 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.
>
>
>     * <#topic5> XForms Basic 1.0, 1.1
>
> 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: <#ACTION2> Leigh to update confusing Schema 
> profile sentences for editorial update.
>
>
>     * <#topic6> XForms at XML Conference
>
> http://lists.w3.org/Archives/Public/public-forms/2007Jun/0005.html
>
> 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: <#resolution1> We go with Monday Dec. 3rd for 
> the XForms Evening at the XML Conference
>
>
>     * <#topic7> Forms Joint Task Force with HTML WG
>
> 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.
>
>
>     * <#topic8> F2F
>
> 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: <#ACTION3> Erik Bruchez to update 
> http://www.w3.org/MarkUp/Forms/specs/XForms1.1/xforms11.full.zip with 
> diff-marked insert changes.
>
>
>     * <#topic9> Editor action item
>
> http://lists.w3.org/Archives/Public/public-forms/2007Jun/0008.html
>
> John Boyer: Just assign it to me.
>
> Action 2007-06-6.4: <#ACTION4> John Boyer to handle 
> http://lists.w3.org/Archives/Public/public-forms/2007Jun/0008.html
>
>
>     * <#topic10> Instance replacement fix needed
>
> http://lists.w3.org/Archives/Public/public-forms/2007May/0081.html 
> http://lists.w3.org/Archives/Public/public-forms/2007May/0065.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.
>
>
>     * <#topic11> IRC Minutes
>
> http://www.w3.org/2007/06/06-forms-minutes.html
>
>
>     * <#topic12> Meeting Ends
>

Received on Wednesday, 6 June 2007 17:50:53 UTC