W3C Forms teleconference February 28, 2008

* Present

Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Joern Turner, DeramLabs
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net
Nick van den Bleeken, Inventive Designers
Rafael Benito, SATEC
Roger Pérez, SATEC
Sebastian Schnitzenbaumer
Doug Schepers, W3C
Steven Pemberton, CWI/W3C
Susan Borgrink, Progeny
Uli von Lissé, DreamLabs
Keith Wells, IBM

* Agenda

http://lists.w3.org/Archives/Public/public-forms/2008Feb/0078.html

* Previous minutes

* Upcoming telecons

John Boyer: The US changes on to DST March 9. When does Europe change?
Nick van: [irc] March 30. [until then] we have the call one hour earlier starting March 12.
John Boyer: March 12, 19, 26 the call will be one hour earlier in Europe.

* Newsletter

Leigh Klotz: I made an outline.
John Boyer: We should say that XForms 1.2 is part of the Forms Task Force deliverables.
Leigh Klotz: Done. I'll turn this into prose and send it out.

* Schema typo

http://lists.w3.org/Archives/Public/www-forms-editor/2008Feb/0002.html

John Boyer: I'll fix this and Mark should too in his Schema.

Action 2008-02-28.1: John Boyer to fix schema issue http://lists.w3.org/Archives/Public/www-forms-editor/2008Feb/0002.html

Action 2008-02-28.2: Mark Birbeck to note check fix in prototype modularized Schema for http://lists.w3.org/Archives/Public/www-forms-editor/2008Feb/0002.html

* We should automate boolean-from-string() on the boolean MIPs (relevant, readonly, constraint)

http://lists.w3.org/Archives/Public/public-forms/2008Feb/0077.html http://www.w3.org/MarkUp/Forms/wiki/Unified_evaluation_context

John Boyer: We discussed doing this streamlined. We can treat boolean-from-string and unified as separate issues.
Nick van: The unified context example shows a normal bind with a nodeset and a context that overrides the evaluation context. In the insert example, it applies only to the first node in the nodeset. I don't think we want that. Normally bind nodeset points to all the nodes, not just the first.
John Boyer: Inside bind, we have a "repeat" mentality, so each node of the bind nodeset gets a separate calculate.
Nick van: OK. So I can just copy it completely.
John Boyer: Maybe a second example that makes it clear that the MIP is repeated for each node in the nodeset, not the context.

<bind nodeset="purchaseorder/items/item/lineTotal" calculate context=".." value="quantity * price">

John Boyer: This shows another example of why you would want to use it. It streamlines getting the data from another instance. One of the main things we're trying to achieve is enough expressivity in 1.2 that the implied or simplified use case where the attributes are on a form control as in 
input [readonly] name="result" calculate="a+b"
input name="a"
input name="b"

John Boyer: If they don't want to be bothered with a bunch of dots, we should have enough in our model so that the simplified on-the-glass syntax can easily be converted to the model. Converting calculate="../a+../b" is hard because you have to parse the expression.

Erik Bruchez: I hadn't realized that there was a proposal for a new syntax. The dot removal is mainly for cases without an explicit model, right? So if you write calculate="a+b" do you really need to translate this into nested binds in the implicit model? You're not going to have nested components in the view; it will be a quite flat hierarchy. I'm not sure I understand the use case where we need to change the binds.
Nick van: I did some writeup on creating groups or repeats: http://www.w3.org/MarkUp/Forms/wiki/Add_model_item_properties_to_UI_level
Erik Bruchez: So the hierarchy of XML elements is not flat in that case.
John Boyer: There is a desire to express the calculate as an element child of bind. That makes some expressions easier to write. But it also opens the door to being able to express, for example, multiple constraints under the same node. For MIPs where that makes sense, it makes it easier.
Leigh Klotz: We've been turning our attributes into elements pretty much universally.
John Boyer: We're doing it for a different reason: going past adding attributes to them and in this case doing it so we can reset the context.
Leigh Klotz: We're doing it for syntax, since in both cases we wanted to add an attribute to an attribute.
John Boyer: And also because we wanted, in this case, multiple constraints, which you cannot do with attributes. You can't do it with multiple attributes of the same name so you make them elements. It's unwieldy to write big boolean OR and AND expressions.
Leigh Klotz: That begs the question of whether you want to have a container element that says how to combine them.
John Boyer: We have that as a starred item.
Nick van: Two binds that have nodes in common isn't helped by child elements; you have to split it into three. One for nodeset a, one for b, and a third for nodes in common.
John Boyer: Generally speaking you're right; you will need separate binds that happen to match some of the same nodes. In my view, as soon as we open the door to more than one constraint on a node, it doesn't matter if they're all in the same bind or not. I think it in unified context about combining. http://lists.w3.org/Archives/Public/public-forms/2008Feb/0022.html
Leigh Klotz: Why not use and and or or allof/anyof rather than constraint/@operator.
John Boyer: Sometimes there's no opportunity to create a child element; you could have two binds with constraints and the default combination is and.
Erik Bruchez: You could imagine using an and operator to say a node is valid if all constraints are invalid; the type constraint, the constraint case, etc. You can't use grouping go do that.
Nick van: [irc]

 <bind nodeset="//*[@type=<code>b</code>]" constriant=".."/>
<bind nodeset="//*[@class=<code>c</code>]" constriant=".."/>

Erik Bruchez: I'm not saying there are no workarounds, but you have to use a generic AND or OR operator to group.
John Boyer: If you have two different binds that are both on the node X, then it's helpful to make an attribute to make a constraint on the node.
Leigh Klotz: I see it's not just a syntax issue as it lets you split up the binds. But what does it mean if you have a second bind added to a subset of nodes combined with OR or AND?
John Boyer: The default would be AND...the example is a little confusing.
Erik Bruchez: If you had value>10 and value<100 then both would have to be satisfied; that makes sense. Just like type, all must be satisfied.
John Boyer: The example in the attribute based way would add together: 
<bind nodeset="X" constraint=". > 10"/>
<bind nodeset="X" constraint=". < 100"/>

John Boyer: Only if I want to override with OR would I add it. Child elements of bind is not just a good idea for calculate. It also corresponds to the on-the-glass version. It can help simplify.
Erik Bruchez: I have nothing against the context attribute; I think it's great. I have nothing against the constraints in the view. I think we need to solve the problem of allowing multiple binds to refer to the same node. From there, we are designing a new feature and are getting sidetracked. As far as simplicity, the use of the context, I don't see much simplicity there. For advanced XForms authors using XPath, using context=".." and then an expression would work, but I don't think it makes things easier. It's not a simplification if you write it yourself.
John Boyer: This is for making the on-the-glass syntax correspond to the model.
Leigh Klotz: It's so you can write an XSLT that converts the glass syntax to full XForms model syntax without having to include an XPath meta-evaluator.
John Boyer: Right
Erik Bruchez: Can't you just write context=".." on the bind.
John Boyer: No, it's before the bind.
Leigh Klotz: I think all of this stuff is stuff we're already doing, but we need to make it work together. I think we should look at all our attributes and see if child elements are valuable. It's good to have a principled stand. We should use attributes when they are convenient. There are wars fought in XML/SGML land (and now JSON and others) over attributes and we should have a principled stand.
Erik Bruchez: Attributes are easier to type, certainly.
John Boyer: Authors should use attributes where they're easier to use. For programmatic authoring of XForms models that correspond to on-the-glass technique using nested elements is easier. We can show the task force that there is an easy mapping between what they want to write and the corresponding XForms model that implies. Making that transformation easy is critical for us.
Leigh Klotz: I think that's ok but I'm not sure about the constraint combination syntax; we need to look at it.
John Boyer: ... That's part of how I ended up at an attribute.
Charlie Wiecha: [irc] agree with Leigh...worried about creating a new expression language in angle brackets
John Boyer: With Leigh's earlier comment, Leigh was thinking of element names rather than an attribute. We're still talking about whether it is elements or attributes.
Leigh Klotz: No, I just asked why you used constraint/@operator=and rather than <and> I see it's because you need to group siblings under different binds. However, I'm not sure either is the right solution; there may be a better way to combine them.
Erik Bruchez: You can group with multiple binds and that's the default, but container elements such as AND or OR could give you what you need. ...
Nick van: [irc] we need to check what the use cases are for needing us to create our own expression language
John Boyer: Right, as long as we can have multiple constraint, readonly, relevant, then we can use logical AND and leave off the operator for now.
Charlie Wiecha: [irc] sounds like it's going in the right direction...keep it simple
John Boyer: Except for readonly which is kind of opposite.
Leigh Klotz: I prefer the tri-state ones like CSS has.
John Boyer: We don't stop processing for constraints; returning true is the same as returning don't care.
Leigh Klotz: Then you have no way of doing OR.
John Boyer: How do you do OR?
Leigh Klotz: Instead of saying valid if x < 3 you say invalid if x isn't < 3.
John Boyer: I see. Suppose I had a constraint in today's language that had "a or b"
Charlie Wiecha: not a and not b
Mark Birbeck: [joins] Why are we doing this?
Leigh Klotz: http://lists.w3.org/Archives/Public/public-forms/2008Feb/0022.html is the context.
Mark Birbeck: Have we decided that input MIPs propagate to the model?
Leigh Klotz: You'll have to address John, but we're discussing it in that context.
Leigh Klotz: If we want to avoid pointy expression languages, defining the problem such that it doesn't occur in the 80% case is good, so I suggested splitting the MIPs into tri-state as in CSS and then combining them all with a simple rule: relevant/irrelevant
Nick van: [irc] read-only/read-write valid/invalid
Leigh Klotz: So this is one proposal for the combining and we don't need to finish it on the phone.

Mark Birbeck: So what about the MIPs on input controls.
Mark Birbeck: ...
Nick van: http://www.w3.org/MarkUp/Forms/wiki/Add_model_item_properties_to_UI_level
John Boyer: It's a fairly big thing for 1.2 to have MIPs not on the MIP.
Mark Birbeck: We have MVC but that doesn't mean there's only one. We can have multiple views on the model. You can't have a node in the instance data that's viewable as a string of text if it's set to a type of date. There's use cases where that's not desirable, propagating to the view. But there are many use cases. Picking up someone else's model that we don't have to alter as a black box is good O-O practice.
John Boyer: We need something as simplified on-the-glass syntax. Separately, we need to be able to control properties of user interface controls. If you look at XForms 1.1 now, there's the notion of model relevance; there's also an implicit and not-yet-but-subtle notion of control relevance. You don't have a direct way of overriding it or setting it. It's based on teh data layer plus UI containment.
Leigh Klotz: ref=.[x=y]
John Boyer: And whether you're bound to a node. So we may need control relevant vs. data relevant.
Mark Birbeck: If you have a set of automatic rules that propagate, then in a way you don't need the distinct attributes. A bind with readonly would set the model readonly value which would propagate to all controls. On the control, we could say it only applies to the control. If someone wants, as part of the onramp with bind distinct from model, then the author could optimize by a bind statement to replace readonly on three input controls.
John Boyer: If those three input controls were bound to the same node?
Mark Birbeck: Yes, at a certain point, or a date would be a better example. Create a bind statement, bind x type=date. That's a nice, natural flow. It wouldn't be wrong to have type=date on five different controls, just like it's not wrong to write your code inefficiently. It makes it natural without having to understand MVC, which they may eventually discover and get even more benefits.
John Boyer: What about calculate?
Mark Birbeck: I don't agree that calculate should go on input. I think output value=expression is fine and that's already in the UI, not the model.
John Boyer: We already have the ability to bind a node to an input.
Mark Birbeck: So use output. If someone's entering their name in the form, output is fine. If you're summing values, then you're in bind territory anyway.
John Boyer: How do you want up writing a tabular purchase order without explicitly using bind. It seems like I should be able to do that. I kind of have to have a data view of what's going on.
Mark Birbeck: I see. Output isn't quite enough.
John Boyer: You'd need output with ref and calculate.
Mark Birbeck: I was thinking of output value=. But we should look further at the name= syntax, a shorthand for a named node. Maybe $name=$x+$y. But I haven't thought it the way you are. That would be the value of the node and you could sum the invoice lines and the total and have an input control for the tax rate and use that in other parts of the form.
John Boyer: Or if the tax rate were a constant or obtained elsewhere, the subtotal and grand total calculations would be... Maybe the next step here is to try to take the simple PO scenario and express it in simplified syntax until we're all happy with it.
Mark Birbeck: Hmmm...
John Boyer: I have a starting point. Charlie:[irc] +1 for example-driven approach
Steven Pemberton: [irc] +1
John Boyer: Mark, would you work with me on it, maybe for next week.
Mark Birbeck: That's a very good idea.

Action 2008-02-28.3: John Boyer and Mark Birbeck to put together simplified syntax straw proposal for purchase order example to make sure we have repetition capability and non-trivial calculation.

Mark Birbeck:

<input name="surname" />
<output name="full-name" value="concat($first-name, ' ', $surname)"  />
This is what we discussed before, but the difference now is that "full-name" could also be referred to in the same way.

* XForms 1.2 Requirements

John Boyer: Where do we publish them and how?
Steven Pemberton: If we publish them in our own space we can go ahead. The very first version was in TR space, but there's no reason. It's a bit strange to do that as it then becomes a WD that never goes anywhere. Personally I'd put one in our own space. It is easier to update and it still reflects our thinking.
John Boyer: Is there some kind of requirement that a note go into TR space?
Steven Pemberton: If you want it to be a Note you can but just a document that belongs to us is OK. We can take the document and publish it as a Note later if we need.
John Boyer: So there is no requirement to publish a requirements document as a note?
Steven Pemberton: As far as I know there is no W3C requirement to publish a requirements document.
John Boyer: What is the purpose of a WG Note?
Steven Pemberton: It's usually something that starts as a WD but then stops.
John Boyer: As long as we can publish them in our own space.
Leigh Klotz: Might as well put them in the wiki for now. I read that Mozilla got their contributions up by a factor of ten by using a wiki instead of DOCBOOK format. We can always go to XMLSPEC at the end if we need to but there's no reason to go through it just to add a new line.
John Boyer: Right
Steven Pemberton: Right

* IRC Minutes

http://www.w3.org/2008/02/27-forms-minutes.html

* Meeting Ends