W3C Forms teleconference September 29, 2010

* Present

Alain Couthures, AgenceXML
John Boyer, IBM
Steven Pemberton, CWI/W3C (chair)
Philip Fennell, MarkLogic
Erik Bruchez, Orbeon
Leigh Klotz, Xerox (minutes)

* Agenda


* News

Steven Pemberton: I had a call with PLH at W3C yesterday, and he told me that he recently visited Xerox, and that they showed him a copier where the UI was done with XForms. He was shocked because that was his office's machine, and he hadn't realised he'd been using XForms daily for so long.
Leigh Klotz: Yes, Philippe Le Hégaret was in Rochester.

* Lyon


Steven Pemberton: I've explained why not as many are attending as said at the beginning of the year. The registration fee goes up after October 22.

Steven Pemberton: We're booked to meet MTRF; I'd say 9-5 Lyon time, unless other suggestions?
Steven Pemberton: 9-5 Pacific?
Leigh Klotz: So a shorter overlap for teleconference?
John Boyer: No.
Steven Pemberton: We should start on agenda items in the next few weeks.

Action 2010-09-29.1: Steven Pemberton to produce agenda shortlist for Lyon F2F/TPAC.

* Example 11.9.n, 11.9.o question from Claudius Teodorescu


Leigh Klotz: Is this answer sufficient?
Steven Pemberton: "Does anyone have any idea on which has to be the user experience with these XForms examples?"
Leigh Klotz: I believe they do save to file.
Alain Couthures: Yes.
Leigh Klotz: Alain's answer http://lists.w3.org/Archives/Public/www-forms/2010Sep/0040.html
Steven Pemberton: We don't specify the experience; we do specify user experience occasionally to ensure something simple. I'm happy with this answer. Anybody else?
John Boyer: They are marked as optional to implement.
Leigh Klotz: As Alain points out, they will eventually be implementable.

* disabled controls bindset failure

http://lists.w3.org/Archives/Public/www-forms/2010Sep/0011.html http://lists.w3.org/Archives/Public/www-forms/2010Aug/0009.html

Steven Pemberton: Michael Sperberg-McQueen is preparing a tutorial for TEI and these comments are from his preparation.
Leigh Klotz: It's about whitespace normalization.
Steven Pemberton: He says "consider whitespace" for data types.
Leigh Klotz: We say that the form controls convert value space into lexical representation, so if you input bound to xsd:integer and type or otherwise indicate space-space-space-42 the form control might refuse the spaces, or it might elide them when putting the data into the instance. I believe these are allowed.
John Boyer: I don't think XForms places obligation on form controls to do whitespace conversions, particularly given that this example is xf:value. The xf:value element had spaces in it. As it stands, our general response to xf:value is not to put spaces, becuase we use space-separation for multi-select. XPath does a literal string comparison; as far as XPath is concerned, those are two different strings.
Steven Pemberton: As long as you don't do normalization. It would be nice if providing a value via that path got the same results as providing it by the other path.
Leigh Klotz: Or by instance data: is <x> 1</x> valid?
John Boyer: For the idea that we be turning " 1" into "1" automatically, you can't do it at all. Just like an input field lets you type space.
Leigh Klotz: I don't think an input is required to let you type space; it can refuse it if it's a numeric field.
Steven Pemberton: I'm not very good at the spec-ese Michael is talking about; he says it's not a bug, but says it complains about the space.
Leigh Klotz: So is it schema valid for element values?
Steven Pemberton: He says it ought to be. "When attributes and elements are governed by those whitespace-normalizing types, then the string in the input document is whitespace normalized before it is checked to see whether it's in the lexical space of the type."
Leigh Klotz: That's spec meta-language. Is the document valid or not.
Steven Pemberton: For a pure string, you don't want it normalized. For list-items, whitespace normalization would be a good thing. I think it comes down to what we think the right behavior is.
Leigh Klotz: My guess is that they won't accept the document.
John Boyer: No, they will accept it. The Schema document defines the lexical space as the characters after normalization. So, should we say that UI controls should whitespace-normalize before putting the data in? That makes sense. We also need to decide what constitutes being out of range. It's not about input, which is a too-simple example. Consider the select1 example with "ewbrl " as the value. If we say a select1 does whitespace-normalization before copying to the data layer, then the way we indicate which item has been selected is by matching that value-element content.
Leigh Klotz: Then we'd have to convert to whitespace normalization before data matching in select1.
John Boyer: We'd whitespace-normalize the value before comparing to xforms-value elements. I don't think the spec goes so-far as to suggest that.
Steven Pemberton: What datatype is xf:value?
John Boyer: It doesn't have a pre-determined type. It provides values for the UI binding to the data node, which itself is typed. Here, the majority of implementations have copied the xf:value data, including spaces; that's schema-valid because the Schema does the whitespace-normalization before type checking, but XPath doesn't whitespace-normalize strings so their XPath expression failed. They could simply call whitespace-normalize.
Steven Pemberton: So it should have worked?
John Boyer: You have to squint really hard at how friendly we expect select and select1 to be to decide that it ought to work.
Steven Pemberton: There's no datatype in the original example so it's a string.
John Boyer: So it certainly shouldn't have worked. And the answer is to call XPath normalization.
Steven Pemberton: Now if it had been integers the spaces would have been stripped?
John Boyer: No, but it would be comparing with an xpath number, not a string. XPath would cast to number and strip the spaces.
Steven Pemberton: Then I'm happy we've done the right thing.
Leigh Klotz: I'm still in shock of not understandign the whitespace behavior of XML Schema but I should get used to that. But how about the form control and spaces in the input integers fields?
John Boyer: I don't let the user even type it on the screen.
Leigh Klotz: That's what I thought would be allowed.
Steven Pemberton: And paste as well shouldn't be problematic.
John Boyer: Or pre-pop data or web-service return results. I believe when you bring up a form, nothing should change, modulo xforms-ready etc. If you just bring up the form, the UI controls shouldn't change the data.
Steven Pemberton: That would be bad.
Steven Pemberton: Are we OK?
Leigh Klotz: Do we need to answer?
Steven Pemberton: I'll answer.

Action 2010-09-29.2: Steven Pemberton to answer http://lists.w3.org/Archives/Public/www-forms/2010Aug/0009.html and explain XForms and whitespace.

* Dynamic Dependencies in XForms 1.1


John Boyer: We got a comment on dynamic-dependencies in XForms 1.1 CR. We had two possibilities for how we could have gone. One way is highly constrained, that you are accessing a leaf node value. For example, a[@attr="X"]/b[@attr="X"]/c. Collapsing the dependencies is where we went into trouble. We went with the most permissive, which uses the most dependencies. I think we need the most restrictive in the data layer and the most permissive in the UI layer. I don't think implementors have implemented this definition of reference because it seems to create circular references in simple normal forms if the form author doesn't carefully choose the binds, because otherwise the recalculation engine breaks down. The most lax definition, now in the spec, says that anything which matches a node test is counted as a reference. So we match every A element, regardless of whether the predicate selects it or not; then within the a, we match every attr, and then create a reference on every selected b and every attr, and then for each selected b, then every c element. This makes XPaths more responsive to changes to nodes that are in the predicates without having to call rebuild. It gives us a certain amount of support for model-layer "dynamic" dependencies, so that even if you changed c to another node by changing the attr attributes, the new node c would still be the MIP target. This seems like a good thing if you only have one calculate, but because it creates multiple references to all ancestor elements for the leaf nodes (a's and b's), as soon as you have 2 or 3 calculates in the same form, they start to have common references, and it becomes difficult for the calculation engine. It seems to run into situations where none of the nodes become degree zero, and so one behavior could be fail, or another to evaluate in random order. Most implementations seem to do evaluate randomly when nothing goes to degree zero; what ends up happening is that bind order governs whether your form works. I'd like to have a form example that illustrates this with a few computes. Our implementation only creates references to to leaf nodes, and to nodes with children. As a result, we don't get this problem with the spec. We found we had a not-quite-enough test on one of our own and that was closer to what the spec says and it causes problems. So does anybody else implement the touch rule for nodes?
Steven Pemberton: It sounds like we need a form from you that illustrates the problem so people can test against it.
John Boyer: You can't just test a form because there may be a compensating accident, or rebuilds being done all the time, or that the form works for some other reason. It seems to me that for a UI binding, the spec definition is a particular good one, and listen to as much stuff as you can. But to decide what a calculate listens to (and avoid circular dependencies) it should listen to less stuff, but the downside is that there are cases where a calculate would not update properly until you do rebuild. I think if anybody actually implements this their forms aren't doing what they should and I believe that people aren't actually doing this, and so I think an erratum would be particularly appropriate.
Steven Pemberton: Please provide an example that makes it very clear where it could go wrong.
Erik Bruchez: An example would help. We do not implement the dependency algorithm in the model at all. I don't know about the newer implementations such as XSLTForms. We are now working on static analysis of XPath dependencies and it rings some bells: for example, returned nodes vs. nodes it depends on vs. nodes that are iterated past. Maybe there's something to dig there and perhaps we need some distinctions.
Steven Pemberton: What do you mean by it doesn't implement the algorithm?
Erik Bruchez: Everything is evaluated in order.
Steven Pemberton: No optimizations?
Erik Bruchez: Correct me if I'm wrong but, there are two reasons for the dependency algorithm: one is for calculation order and the other is for performance. We haven't hit any cases where we need that feature. So far we haven't implemented it.
Steven Pemberton: It's a little worrying to me that we have this in the spec and it's somehow not necessary.
John Boyer: Except for calculate, constraint, relevant, required, and readonly don't (yet) provide an ability to refer to the result of a MIP. So all MIP formula results are leaf nodes. So running them in order is sufficient. And with calculate, you care only if calculates are used by other calculated values. c=a+b with a and b user input, and then d=e+f with e and f being user input, any order will do.
John Boyer: My loan form example with monthly payments followed by total payout (total*duration) is dependent on monthly payment first.
Steven Pemberton: Doesn't it only save time?
John Boyer: You have to do it before the last time, yes. The optimization is to do the calculations the least number of times. If you're doing the algorithm that determines the order but there are too many references generated by the current spec rule, the order-generating algorithm won't generate the right order and you might run the total payout on the old value of monthly payment, and then run monthly payment. So it would be the wrong order. If you changed the principal from 10,000 to 20,000, and you run the total*duration by accident, it's wrong.
Steven Pemberton: You're worried about an ordering algorithm that gets the order wrong.
John Boyer: Because it can figure out the order only when the references are crisp.
Steven Pemberton: We're out of time, but, why do we care at the level of the definition? All we need to say is that the right answer come out, and we don't care as long s the answer's correct. If an implementation wants to do it, it could calculate multiple times.
John Boyer: That would be a great answer for a future version to figure out when references change and auto-rebuild.
Steven Pemberton: I had an implementation long ago of something similar where values had a dirty flag. Changed values were marked as dirty and the whole thing worked itself out.
John Boyer: We were doing the first simpler ones. Spreadsheets ran all the calculations again and again. The problem is that at some point you need to have some "big" limit, like 25, to decide if it's circular. It turns out to be inefficient. The order dependency algorithm now is linear-time or optimal, but it has limitations. It can't decide when the dependency graph itself has changed because it uses a snapshot.
Steven Pemberton: We're out of time but this is an interesting issue. I'm a big fan of using XForms principles to say what it should do and not how, defining XForms declaratively.
Erik Bruchez: I second this. That's why we do it. The algorithm is extremely detailed and doesn't leave doors open. I am one of the people who raised the comment about dynamic dependencies. We left some things unclear.
John Boyer: I'd like feedback from implementors on how references are generated.
Steven Pemberton: That would be great if implementors could do that.

* IRC Minutes


* Meeting Ends