W3C Forms teleconference March 19, 2008

* Present

Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken
Rafael Benito, SATEC
Doug Schepers, W3C
Steven Pemberton, CWI/W3C
Uli Lissé, Dreamlabs
Keith Wells, IBM
Susan Borgrink, Progeny
Mark Birbeck, x-port.net

* Agenda

http://lists.w3.org/Archives/Public/public-forms/2008Mar/0058.html

* Previous minutes

* XForms 1.1 Test Suite

http://www.w3.org/MarkUp/Forms/Test/XForms1.1/Edition1/driverPages/html/index.html

Keith Wells: I added the insert and delete examples from Appendix B and added a showcase of the new features. It's there for review. It would be appropriate now to ask for review for accuracy. Also, I'm creating a test suite harness, probably using Selenium. We don't know how it's going to work out, but so far I'm pleased with the results.
John Boyer: Would now be a good time to link on the WG page?
Keith Wells: Yes.

* XForms Basic 1.0, 1.1

Leigh Klotz: I'm waiting on an implementation report from Mark Seaborne.
John Boyer: I'll contact him if you send me the message.

* Action Item List

http://lists.w3.org/Archives/Public/public-forms/2008Mar/0026.html

John Boyer: Leigh and Eric, please review your items.
Leigh Klotz: Pasting ones I've done into IRC for Nick.

* XHTML2 Call

Steven Pemberton: [joins] We have updated the XHTML 2 call time so Mark and I can be here at the beginning of the call, but I may have to leave early on some occasions.
Mark Birbeck: [joins]

* Message Module

John Boyer: Could you and Steven get this started? We need this example to drive the rest of the module development.
Mark Birbeck: Maybe in two weeks.
Steven Pemberton: We can call on Tuesday.

* Action Item List

John Boyer: We should deal with David's action items. Is Kenneth back?
Steven Pemberton: Kenneth says he will be back after Easter.

* Announcements

http://lists.w3.org/Archives/Public/public-forms/2008Mar/0025.html http://lists.w3.org/Archives/Public/public-forms/2008Mar/0027.html

John Boyer: Steven, is that a news item for our home page?
Steven Pemberton: I'll put it on the home page.
John Boyer: And in the wiki?
Leigh Klotz: I copied the news to the wiki so we could include it on the home page. If it's easier we should do that, but if not, we shouldn't.
Steven Pemberton: I'll look into it.

* Update group page with XForms 1.2 FPWD estimate

John Boyer: What do you think of April? [No response.] I'll assume April's OK then.

* Make progress on "Add Model Item Properties to UI Level"

http://lists.w3.org/Archives/Public/public-forms/2008Mar/0055.html

John Boyer: Charlie sent in a note saying he was uncomfortable with $ and perhaps we should consider E4X. My response was that we already have pluggable expression languages in the XForms 2.0 bucket, but one thing occurred to me. We have two simplified syntaxes: one has $ in it and the other doesn't but both are about two lines. Then a little further down we note that if we combine our understanding of the two canonical forms that make the two simplified bits of syntax work, the result is that both of them work fairly seamlessly. That expression works equally well.
Mark Birbeck: Because it is a bind, it doesn't care what the context is?
John Boyer: And because it is a variable; the bind for the line total is inside of the bind for the row, so $price and $quantity are inside another bind, and in the simplified syntax, it's the output calculate that's inside the repeat.
Mark Birbeck: You can put context=".." and it's ignored when using $.
John Boyer: So both end up working.
Erik Bruchez: It's always worked; I'm worried about the "way out the woods" as you see it.
John Boyer: We have to propose a simplified syntax; we can propose two alternatives, both of which work and both of which are useful ways for people to express themselves. All we have to do is describe what that simplified syntax implies for an XForms processor with an MVC split. The original canonical form for the non-$ augmented with the semantic that every named bind produces an XPath variable (from the second canonical form), we have a canonical form that can drive both alternatives for a simplified syntax. So it works, $ or not.
Erik Bruchez: As far as the binds are concerned, you could use them or not. What would you do in the view, use $.
Mark Birbeck: You could use either or both.
John Boyer: You could say $price * quantity. It would still work.
Erik Bruchez: Is it a way out of the $ completely or is the idea that you could still support bind as an XPath variable?
John Boyer: That's what I'm saying. If we say XForms 1.2 model supports two things:

  1. Every named bind creates an XPath variable
  2. Children of bind set up calculates and other MIPs and can override the context.

John Boyer: Then we have a simplified syntax proposal that works with or without $. My gut feel is that we lead with the $ and that keeps everything flat. Then our secondary example shows how to do this without $. Without $, if you look at the calculate for the subtotal, it needs to use XPath "/" for subtotals. Both are shorthand for the canonical form.
Mark Birbeck: Would the new calculate element have a context of ".."?
John Boyer: It would behave as it does by default now. It would be context="." unless you specify context="..". But an author wouldn't write that; the simplified syntax would imply that construction, so the simplified syntax would not be dot-dot infested.
Mark Birbeck: With readonly and relevant can you use those as child elements on inputs and outputs? That's why I'm asking that the context attribute is implied?
John Boyer: It's spelled out in the canonical form, which contains an XForms bind, and that bind expresses the dot-dot, but there is no dot-dot in the simplified syntax.
Mark Birbeck: Next step: How do I make the product readonly? Do I put a readonly on the select1? That becomes a readonly attribute or readonly element with context=".."?
John Boyer:

<select1 name="X"  readonly="some/expression"

John Boyer: So your question is, does that become this? 
<readonly context=".." value="some/expression"/>

Mark Birbeck: I think it would have to be.
John Boyer: Yes, whether it is regarded as a child of the element or a child of the bind to named X that is on the select1. My gut feel would be to keep these as all implying MIPs. We have a separate feature for readonly controls we're going to work on.
Nick van: <select1 ref="X" readonly=".."> should become <readonly value=".."/> if you use ref instead of name so you don't have to use context=".."
John Boyer: Yes.
Mark Birbeck: That's true.
Nick van: We have to be careful in the spec.
John Boyer: I see the name attribute as a shorthand for creating the named bind and then adding MIPs to it. If someone doesn't use the name attribute then they aren't getting at the shorthand.
Mark Birbeck: I'm not concerned about that; if you take something like this I want to insure that as we build this canonical form, where do we ask the XForms author to jump to XPath: 
<output id="bonusmsg" value="$BonusMsg" relevant="$Subtotal > 100" />

John Boyer: They can just not use the $ and get at the XPath.
Mark Birbeck: Only if we insure that the easy things are easy. 
<output id="bonusmsg" value="$BonusMsg" relevant="Subtotal > 100" />
. It could be anywhere in the hierarchy. If it's at the same level as BonusMsg then it works.
John Boyer: The value attribute doesn't provide the evaluation context.
Mark Birbeck: Well...
Mark Birbeck: This will work regardless of where Gift is in the structure: 
<input name="GiftMsg" relevant="$Gift = true()" />
But this won't. 
<input name="GiftMsg" relevant="Gift = true()" />

John Boyer: It will if you have an input or output called Gift right immediately proceeding.
Mark Birbeck: I think it's unwise to mix both. 


Nick van: and you should use <input ref="GiftMsg" relevant="../Gift = true()" />

John Boyer: The structure creates the XML. The names just "work out."
Mark Birbeck: Once you start making a reference to something else, the advantage of moving variables is that the reference works out OK even when you move. It isn't going to work if you forget to put the $ on.
John Boyer: If someone has gone with non-$, how do they define the data model instead of implying a data model.
Nick van: If you use named bind, use $. If you use the XPath reference and move outside the group or repeat, it doesn't work.
Mark Birbeck: What I'm trying to think through is how to make it clearer which model we're using.
Nick van: You can combine them.
John Boyer: So you're saying if someone does this, their form will survive UI mutations in which groups are spuriously added? 
<input name="GiftMsg" relevant="boolean-from-string($Gift)">

Mark Birbeck: You're saying you can use $ or not and it will still work. If someone inadvertently doesn't put the $ on, and then move it, it will stop working. I think it's OK. The neatness is that for the addition of one attribute, context=".." we get both scenarios pretty powerfully, and as Nick says, at some point you have to get to XPath syntax. I think it's OK.
Nick van: We do have to spell out how to find the evaluation context especially in repeat, when if you go outside repeat you don't get the current row but the whole nodeset "../..".
John Boyer: I agree we'll have to say stuff like that. The point remains that we're the ones generating the canonical form from the simplified syntax, so if we have $price it will be interpreted relative to the evaluation context and if you mess with that you'll get a different $price, which could be cool, actually. As you just answered, Nick. What if I want to refer to the outside, $lineTotal and there's an answer now.
Nick van: If we support the context attribute on all things. Then we have to define that.
John Boyer: I think it has to be for consistency. context=".." is the conceptual context that everyone else is using in $-syntax alternative 1.
Erik Bruchez: I'm not sure that's quite right; when you think about variables you don't have to think about context.
John Boyer: We have late binding to variables.
Erik Bruchez: We have to think more about someone who has less background about XPath and bind when using the simplified syntax. The names and values are available as variables. That was one of Mark's main points; you can move the control around because you abstract the context.
Nick van: You can't do it if you pull something out of the repeat. It's now the complete nodeset. What does context do on the output control?
Erik Bruchez: You define it based on where the variable is. With, Quantity and UnitPrice at one level, within a repeat, it is the value of the controls at the same level. Outside the repeat, obviously you don't have them.
Nick van: If we do that it's not obvious that the variables no longer point to the row.
Erik Bruchez: We define a reference to a bind within a repeat, the bind resolves the same.
Nick van: With groups you have the same problem, though maybe a problem with IDs. Can we have a group a and a group b both with product?
Erik Bruchez: If you use name it's fine but not ids. You have to assure variables are unique because they conflate to ids.

John Boyer: If I do this

<group ref="../.."> <output name="LineTotal" calculate="$something">
that's independent of how we do the canonical form.
Erik Bruchez: The way it is done now the bind depends on the in-scope context. It could return all the values instead of the one in the current situation. We have to think about where that's going because it can become hard to understand what's going on, if you mix variables and context.

John Boyer: There's a difference between what we tell implementers and what we tell authors.

Leigh Klotz: We're talking about task-action models and surrogate models and the mapping between them, and we need to be clear which we're discussing. See Deidre Gentner.

Uli Lissé: I agree with Leigh; I don't know what' we're discussing sometimes. I don't think we need to be able to mix syntaxes.
Mark Birbeck: I disagree about the mixing; we need to always bear in mind what the simple syntax maps to in the canonical model.
Nick van: [irc] I think we need to be able to mix it. I agree with Mark
Uli Lissé: I don't mean we shouldn't mix simplified markup with XForms markup. I think some confusion comes from putting MIPs on the UI controls with the ref attribute, not with the name attribute.
Mark Birbeck: How do we not do that? We're moving back and forth but if we go back a few weeks, we were talking about the $ syntax, then the repeat problem, and now we're talking about the MIP issue. So we still need to discuss it; it's hard to hold in your head. We're trying to address a lot of issues at the same time.
John Boyer: I think I interpret what Leigh said as what I was getting at before: we have to see what the simplified syntax means and how a user can get to full XForms syntax. We need to make sure we're not addressing cases that aren't for a simplified syntax user. Switching between a UI that uses refs and one that uses names is going to be challenging. What underlying data model is implied with < group ref="./.." />? At some point they'll have to switch over and it won't be a complete new syntax.
John Boyer: I typed in a proposal for the name attribute. Use of name attribute implies the following:

  1. create an instance node at "current" level of XML corresponding to UI structure
  2. create bind with id same as the name [and a nodeset bound to that node]
  3. move all MIP attributes from named UI control to child elements of bind with context=".."

Mark Birbeck: A couple of things; in my original proposal, step 2 was step 1 and bind itself would support lazy authoring just as our current controls do. It arrives at the same point. Then for the canonical form, we don't worry about the instance because that comes from bind. Even after all this discussion, I'm not completely convinced that we want to attach the MIPs to the model instead of the control.
Leigh Klotz: What if we had a choice of the MIP on the bind instead of just on the control or the data?
Mark Birbeck: You mean the bind being a view on the model? That would be different from our current bind but it could be good.
Leigh Klotz: I just want to see if there is another way to think about this rather than MIPs on data or UI.

John Boyer: 4) the UI control is converted from name attr to having a bind attr.
John Boyer: If we had the output calculating the line total, that gets translated (if you look in the canonical form email) that turns into <output bind="LineTotal" .../> the calculate stays there, then clearly we need to be saying that the UI binding does not affect the evaluation context of the attributes.
Mark Birbeck: But calculate is the quirkiest.
John Boyer: Not really different from relevant.
Mark Birbeck: I'd prefer to see an output name="lineTotal" and say it calculated elsewhere, because then we're not saying all controls must set data in the model; if I want it in readonly in one position, the you can do that.
John Boyer: I don't think the data should exist in the control.
Mark Birbeck: That would have been a way around it, and $ refer to the control's value rather than the bind's, but that doesn't work.
Nick van: John proposed to add different attributes for ui-relevant etc.
John Boyer: $X is still interpreted in context of the output even when you do this <output bind="blah" relevant="$X". So if MIP attributes stay on the controls, then they can't be evaluated in context of UI binding

Mark Birbeck: The ability to use relevant and readonly on controls is independent of the $. It's a preliminary step to make controls readonly.
John Boyer: I felt that if we used an actual ref or bind and then clearly you're talking about the control. When you use name, we're copying the MIPs to the model.
Mark Birbeck: The most common thing for a new author would be using name. Why can't calculate float freely in the canonical form? We know MIPs are associated with data, but I might put the calculations at the top of the form.

John Boyer: It sounds like we still have lots of work to do. If there are alternate proposals we need to get them on the table.
Mark Birbeck: We've made some progress. It looks like we can make these things work. We're going beyond the purchase order.

John Boyer: If there are alternate proposals to http://lists.w3.org/Archives/Public/public-forms/2008Mar/0055.html, then we need to get them out there so we can settle the syntax and semantics. Is this the simplified syntax? This decision controls a lot of the stuff we're going to write in the first public draft.

John Boyer: Let's try to close on this next week.

* IRC Log

http://www.w3.org/2008/03/19-forms-minutes.html

* Meeting Ends