W3C Forms teleconference April 2, 2008

* Present

Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net [irc only]
Nick van den Bleeken
Roger Pérez, SATEC
Doug Schepers, W3C
Steven Pemberton, CWI/W3C
Susan Borgrink, Progeny
Keith Wells, IBM
Uli Lissé, DreamLabs

* Agenda


* Previous Minutes


* XForms Basic


John Boyer: Kenneth sent regrets.
Leigh Klotz: Once we get the implementation report, I'll put the dates in and we'll re-do the pub rules check.
Steven Pemberton: I spoke to Mark Seaborne and he said the action item was passed on to him.
John Boyer: I'll talk to Mark.

* Action Item List

John Boyer: Let's get each person with more than 10 to fix one. Mark Birbeck isn't available. I'll commit to doing the "fix the schema issue" as I'm already doing the "purchase order example." Leigh is next.
Leigh Klotz: What are the two CSS ones?
John Boyer: The first one is Appendix G for CSS3 namespace module. The second is to update to reflect in CSS examples.
John Boyer: So you'll do Action 2008-01-16.1 this week?
Leigh Klotz: I'll get started and when I have parts I don't understand I'll send a note to the list.
John Boyer: Steven, there may still be some triage work. So could you do that? There are some about resolved CR items. So send the reference numbers in the right hand column to Nick.

* Behavior of replace=text for submissions that retrieve non-text


John Boyer: We talked about this last week; we decided not to adjust 1.1 but would do this in a future issue.

Action 2008-04-2.1: John Boyer to write up spec-ready text proposal for 1.2 for Behavior of replace=text for submissions that retrieve non-text as in http://lists.w3.org/Archives/Public/public-forms/2008Mar/0079.html

* Basic XML Schema Patterns for Databinding version 1.0 Last Call Apr 30


Erik Bruchez: I had a quick glance at it and may be wrong. It looks like a standard way of implementing use cases, as there are multiple ways of doing some things. If you follow the patterns in the spec, then the hope is that you'll achieve higher interoperability among tools that process XML schemas, so you can create XML documents and other bindings from the Schemas.
John Boyer: It sounds like they're trying to figure out ways to get from Schema to other things. They don't mention XForms, or XML. The spec just lists XPath patterns.
Uli Lissé: [irc] in the java world there are many databinding tools. they are often used in web services stacks like axis. the schema is used to generate a class tree implementing structure and validation rules prescribed by a schema.
John Boyer: It seems like it might be relevant to us; we should decide whether we have any comments we need to make about the spec. Is anyone involved or interested in automatic generation of XForms?
Erik Bruchez: Maybe.
John Boyer: Please get back to us on this.

* XML Base PER June 30


Steven Pemberton: I can review this for XForms and XHTML2. I anticipate no problems at all as it's just errata republished as a PER.
John Boyer: Where does this apply?
Steven Pemberton: Anywhere there are urls.
John Boyer: Any application to instance data nodes of type anyURI?
Erik Bruchez: We discussed this at some point, with xf:load and whether we decided not to do xml:base resolution for instance data.
Nick van: [irc] I noticed that they completely rewritten '3.1 URI Reference Encoding and Escaping'

Action 2008-04-2.2: Steven Pemberton to review XML Base PER June 30 as in http://lists.w3.org/Archives/Public/public-forms/2008Mar/0087.html

* Forms Task Force

http://lists.w3.org/Archives/Public/public-forms/2008Mar/0097.html http://lists.w3.org/Archives/Public/www-forms/2008Feb/0016.html http://lists.w3.org/Archives/Public/public-html/2008Feb/0251.html http://www.w3.org/2007/10/forms-tf/ http://www.w3.org/2007/10/forms-tf/charter-proposal http://www.w3.org/mid/op.t2kr1qnf64w2qv@annevk-t60.oslo.opera.com

John Boyer: We are getting closure to the simplified synstax
John Boyer: I'd like to continue pushing forward on engagement with the task force.
John Boyer: I think our simplified syntax is quite a bit shorter than canonical form.

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


John Boyer: Is anyone uncomfortable with using the name attribute to imply we want the special behavior of a set of binds? That's #1. For #2, there is a naming convention that allows you to refer to the names that have been typed directly within calculate expressions. So there's a naming structure in the binds that and there's an implied context=".." so that calculates being applied to these UI controls are applied relative to the in-scope evaluation context node, as opposed to the node that might be indicated by the UI binding that the name attribute implies. That makes simplified syntax without $ work. Then #3 says that binds will be addressable in calculations by using the name that is the name of the variable, so that someone can do $ instead of / separated.
Mark Birbeck: [irc] Hi everyone. Sorry I can't make the call. John has mentioned in a separate window that you might be close to a resolution on the simplified syntax discussion, and I'd like to add my vote if that's the case. My position is still that I favour @name mapping to a flat model. I feel this 'flat model' is best achieved by mapping to <bind; statements, and further that a convenient way to refer to those binds is via the dollar syntax. But note that I am not therefore saying we MUST use the dollar syntax to address the binds, or that binds must represent variables. It just seems to me that the whole package of "@name -> <bind> -> named variable -> reference via $x" is pretty coherent, consistent and ultimately very useful in many different ways, not just in the simplified syntax.
Uli Lissé: John, did you receive my reply?
Nick van: [irc] http://lists.w3.org/Archives/Public/public-forms/2008Apr/0006.html

John Boyer: Uli?
Uli Lissé: I think the variable syntax is not needed and complicates things. I have a feeling, not hard data, that it will collide with real XPath variables.
Charlie Wiecha: That's behind my question, too. I remember a couple of weeks ago. Once we introduce formal XPath variables, are we sure we can do it. See Mark's comments in IRC as well.
Nick van: I believe the binds are like parameters that you put in toplevel in your XSLT. I don't think there are problems.
Erik Bruchez: Nick is saying there are variables in other languages you can declare XPath variables. I don't think using bind to declare variables is a problem. The bigger problem is, I don't know, elegance, or syntactic consistency. It may look awkward to people that all binds implicitly declare variables. I suggested last week that we introduce a name attribute on bind. Then variables would be declared by bind only when you have a name attribute. That would preclude confusion.

John Boyer: Mark, why might we need both ways?
Mark Birbeck: [joins] My main argument is the one I wrote up on the list, of having a flat data model. When I first started talking about the simplified syntax in Venice, the main onramp I wanted to promote was a flat data model for the author. I'm not totally convinced that using context=".." to hide some of the subtleties of hierarchy in XPath is equivalent to creating a flat data model. I mean, that you can refer to something by name and no matter where you are in the UI it will still be that same piece of data. Because we're constructing the data to mirror the UI we don't see that data model, but when you start merging that with your on data, things start to change. So my feeling is that the ability to refer to anything from anywhere within the UI is quite important.
Charlie Wiecha: So the $ syntax would let you ignore the hierarchy? ...
Mark Birbeck: Yes. There was an example before that just worked, but if you then wrap a group around it, and merge the simplified syntax with more advanced XForms concepts, then it starts to break down. So that's what I'm getting at. If you say $subtotal you should be able to move that around and still get the subtotal. The example I gave was the summary page of a shopping cart, with $total. Putting that in many positions within the form, not just in the one place we have, requires a flat model.
John Boyer: Not quite a flat model, but the $ are making the calculations more immune to changes of structure in the UI because the variables will automatically work out their context.
Uli Lissé: You don't need the $ syntax for that.
John Boyer: In your mail, Uli, the output for the total, should be sum row/lineTotal.
Uli Lissé: No, it's by intent. It's the same as with $ but not with $. The generated line indeed has that. There is some parsed-re-writing here.
Nick van: [irc] It becomes hard to identify what path-steps need to be re-written.
Mark Birbeck: Uh
John Boyer: That makes it harder to automate re-writing to canonical form.
Uli Lissé: Really? In what case?
John Boyer: In this case, you would have to write XSLT to parse the expression.
Uli Lissé: Does it have to be XSLT?
Nick van: It is still a path expression if it is just one atom. So it's hard to find.
Uli Lissé: You have to re-write any expression that occurs on a form control with a name attribute. All path-like constructs are like $ syntax, but without the $. You resolve to another control with that name and you get a nodeset.
Nick van: But you can't then use more complicated XPath in those expressions. In my opinion, you can use variables and XPath expressions mixed.
Uli Lissé: Why would you do that?
Mark Birbeck: So you're creating a new path language: when the name is present you parse them one way, and when not present, you parse them another.
Uli Lissé: Yes.
John Boyer: So far we've said that the expressions are preserved, but moved in context to give them different meaning. It's a black box.
Uli Lissé: The calculate expression in your proposal, you have ... so it's not a black box.
John Boyer: I mean, in the canonical form, it doesn't matter which of the two you started with; there is a set of binds and whichever of the calculates appeared in the simple syntax is the one that is copied and it will still work.
Nick van: John is using XPath. You're using the Uli expression language instead of XPath.
Uli Lissé: It's XPath but the instance data isn't there.
Nick van: It isn't the XPath syntax.
Uli Lissé: It's done using static analysis. You'd have to parse with XPath and re-write.
John Boyer: The proposal we're trying to get to is that you don't have to use the $ syntax, but it has some benefits if you use it.
Leigh Klotz: That emergent aspect of this proposal bothers me, that if you have a $ and it works the same expression without $ works mostly.
Mark Birbeck: Any syntax that embeds XPath is going to have this problem, and it's just a question of when the author needs to learn the level of complexity.
Leigh Klotz: I'm just concerned that they shouldn't have to make the leap because of a single-character typo.
Mark Birbeck: Ulrich, I think if we wanted another expression language we would need simply use Javascript.
John Boyer: ...
Uli Lissé: But it is just XPath.
John Boyer: XPath takes only one node as a context node, not four or five. The expression sum/lineTotal is an XPath expression.
Mark Birbeck: It conforms to the XPath syntax.
John Boyer: It isn't XPath because of the evaluation. It would need a context nodeset to evaluate, which XPath doesn't support.
Uli Lissé: It's an XPath expression, but without the same meaning.
Nick van: It's not XPath then.
Mark Birbeck: You need more information than would normally be given; therefore it is more than an XPath parser. THe fact that the syntax is the same is neither here nor there.
John Boyer: It syntactically matches the XPath expr production but it doesn't evaluate.
Uli Lissé: It just depends on the evaluation context.
John Boyer: Which row do you plug into the evaluation context for the summation?
Nick van: [irc] it becomes hard to identify what path-steps needs to be rewritten sum(LineTotal)*AnotherContrl. if you evaluate this expression the LineTotal path expression needs to evaluated against all row elements. the AnotherContrl path needs to be evaluated to another context.
John Boyer: You have to feed in a context node, not a nodeset.
Nick van: I think you can do that in XPath 2.0.
Erik Bruchez: You have context item and position. I think it's the same, but it's a context item, which can be an integer. So it's the same as XPath 1.0.
Nick van: The example I just gave breaks because you need two contexts. That's where it breaks.
Uli Lissé: I don't want to discuss XPath syntax in detail, but I want to discuss $ syntax. I just don't think it's needed.

Erik Bruchez: I suggested the $ syntax. But I also proposed a function control(xyz). We could do bind as well. But I'm not sure what bind tells someone who is new to XForms.
John Boyer: I don't want to type very much. The extra $ is as much as I type. If they want to add extra hierarchy and that changes the naming conventions for things, the know they'll have to put extra slashes because their naming convention changes. Those people won't use $. Then there's the people who will use $ and we should focus on them. They'll get further along before they have to think about UI hierarchy and uniqueness of names.
Erik Bruchez: I like the variable syntax. ...
John Boyer: ...
Erik Bruchez: That's one of the reasons I had for this proposal. We shouldn't use ids for this; that's for unique references. In the model, we have scope, and id is document unique. That's a separate problem.
John Boyer: I think everyone agrees that switching over to bind name would help. That means we don't have to do unions of binds as well.

John Boyer: It seems we need a proposal that can go to full-out XPath and we have that. The $ syntax provides a flatter namespace for a longer period of time for a larger set of users and they can go on longer before they discover they need to use XPath, and they still don't have to deal with canonical XForms, just that the UI hierarchy is creating hierarchy.

Leigh Klotz: This is a secondary point, but what's the difference between <xf:bind name="foo" calculate="123"/> and <xf:variable name="foo" select="123" />.
John Boyer: You can nest binds, but not variables.
Erik Bruchez: Our binds hold only nodesets.
Mark Birbeck: I'm not sure what we're discussing here. binds are not variables. But that doesn't matter. When you get to the XPath expression.
Leigh Klotz: Yes, the XPath syntax is the same. I'm asking about what the canonical form is, and whether it results in a haired-up bind or whether we are really just making an equivalent to xsl:variable here.
John Boyer: There's the nesting argument.
Erik Bruchez: If you did this with variables you have to redo it all the machinery of bind.
John Boyer: Take the binds that are in part 5 of 97 and try to write the variables. http://lists.w3.org/Archives/Public/public-forms/2008Mar/0097.html
Leigh Klotz: So they change in context?
Nick van: They are global variables but change in scope.
John Boyer: So we're creating global variables that change according to where they are referred to.
Leigh Klotz: OK I'm convinced.

John Boyer: I'm not sure how close we are. We may need an extra telecon.
Mark Birbeck: Is it worth a straw poll to see how close we are? If there are a couple of people opposed to it, then we still have to do stuff. If everybody is opposed, I don't know.
John Boyer: It's a pretty long and exhaustive email.
Leigh Klotz: That message doesn't include the change to bind/@name.
John Boyer: Right. But a lot of the details are worked out.

Leigh Klotz: Mark, where do you stand now on the hierarchy?
Mark Birbeck: This is the proposal I had in mind in Venice but it's better. I hadn't worked through the repeat stuff, and my idea fell apart. Also, the point of Erik's on name rather than bind is a big improvement, which is better than my original proposal. I came on the call because everybody was rejecting the $ syntax. I'm not totally wedded to it, I haven't been able to come up with anything better. Most of the AJAX libraries use $ to represent DOM references. It won't look funny and it gives a nice route in to XForms.

John Boyer: Ok, we seem, to be doing a straw poll on http://lists.w3.org/Archives/Public/public-forms/2008Mar/0097.html plus the name attribute for bind.

Charlie Wiecha: [irc] i was originally opposed to having both $ and non-$ notation, but now like the ability to have a "flat" space of names, so I'm +1
Nick van: [irc] Since a couple of weeks, I'm personally convinced that the $ proposal is good proposal for me. So for me we can start working on the details on a separate call
John Boyer: [irc] I like the dollar syntax as an easier way for people to get started and go for longer with a "flat space" understanding of the world, and then they can scale up to full XPath without too much pain.
Leigh Klotz: [irc] +1
Mark Birbeck: +1
Keith Wells: Keith says move forward +1
Uli Lissé: +/-0
Steven Pemberton: +0

Charlie Wiecha: I'm curious about the folks who are expressing 0. Steven?
Steven Pemberton: It's with the background of the idea. I'm not convinced we need to answer this. So, carry on.
Mark Birbeck: I think it's a shame to see simplification in this light. XForms should be sweeping all before it. It needs an onramp.
John Boyer: I've been doing this since 1993 and if we have a way to usher the on-the-glass designers in to MVC it is helpful. The $ stuff for binds, rebuild separated out and the bind function, are all coming out of the core improvements.
Mark Birbeck: The sweet spot is that the model is sitting there waiting for the author. Our stuff looks like it's on the glass, but you have the entire power of a model behind the scenes.
John Boyer: And this checks off the "make something simpler that maps to what we have" so it is substantial.
Charlie Wiecha: I like the idea of thinking of this as a benefit to XForms as well.
John Boyer: I like it and hope others will start liking it. Resolved?

Resolution 2008-04-2.1: Proceed to spec ready text on simplified syntax and canonical form expressed in http://lists.w3.org/Archives/Public/public-forms/2008Mar/0097.html plus name attr on bind as way to create variables

Action 2008-04-2.3: John Boyer to provide spec ready text on simplified syntax and canonical form expressed in http://lists.w3.org/Archives/Public/public-forms/2008Mar/0097.html plus name attr on bind as way to create variables

* IRC Log


* Meeting Ends