W3C Forms teleconference October 5, 2011

* Present

Leigh Klotz, Xerox (minutes)
John Boyer, IBM
Steven Pemberton, CWI (chair)
Alain Couthures, AgenceXML
Nick van den Bleeken, Inventive Designers

* Agenda


* Test Cases


Leigh Klotz: I'm having to write test cases for some features for XForms. We have one implementation of each feature already, either betterForm or Orbeon.
Steven Pemberton: So would our exit criteria be two implementations of each feature?
John Boyer: In XForms 1.1 we went with two implementations of each required feature and one implementation of each optional or recommended feature.
Steven Pemberton: That's great. Nothing changes. I thought we were requiring two full implementations.
John Boyer: That was only for 1.0.
John Boyer: Also, we have topic areas with some information and as we move it into spec-ready text it may be good to go back into those wiki areas.
John Boyer: It would be a pain to leave the test cases until later in the process.
Steven Pemberton: I support that 100%. But we need to have a look at our current sections.
John Boyer: Bottom line, the list is pretty small. There is a section in the new spec with deltas. So we have a bullet list of features.
Steven Pemberton: The list may not be completed.
John Boyer: At least through the last F2F.
Steven Pemberton: I'd like to have another pair of eyes on it to make sure it covers everything.
John Boyer: Then there is the Category:XForms20 list, with the migrated ones.
Leigh Klotz: So put the links to the test cases back in the pages that have Migrated. And a Category:XForms20Test as well.
John Boyer: Would we delete the old text?
Leigh Klotz: Yes, I think we should.
John Boyer: I didn't eliminate a lot of the old directions and so on. But it's in the history.
Leigh Klotz: I renamed "Gee there ought to be a way to iterate" to @iterate. We can streamline the text and leave pointers to the spec and the tests.
Steven Pemberton: So we need action items for people to go back and add test cases to their sections.
Nick van: Joins
John Boyer: We need owners. We should be Darwinian.
Steven Pemberton: How do we get this turned into an action.
Leigh Klotz: One action per person to get them to start test cases.
Steven Pemberton: So an action for each person in the group?
John Boyer: For now, just those listed as editors who have added content, and then going forward.

ACTION-1833 Leigh Klotz to check that his sections have test cases

ACTION-1834 Erik Bruchez to check that his sections have test cases

Nick van: We may need to re-order the tests because chapters moved.

ACTION-1835 Steven Pemberton to renumber existing testsuite.

Leigh Klotz: Maybe they could have ID links instead of numbers, #model-item-properties-calculate instead of
Steven Pemberton: Good idea.

* Proposed note for insert and new functions for XForms 2.0


John Boyer: We've had a couple of email exchanges about this.
Steven Pemberton: Do you want to talk about it or should we discuss it?
John Boyer: The insert action has an implicit claim that if you provide ... and don't provide ... it will be inserted as a first child of a new context node. It strongly suggests we are providing a constant-time operation to insert in the beginning of the child-list of an element. I vaguely recall being intentional about that. It seemed to be that an implementation couldn't claim it wasn't possible to add a first-child in constant time, but it's possible for a last-child. Having a last-child in constant-time would be helpful so perhaps we should have a note saying SHOULD constant time on first-child.
Steven Pemberton: You can't say "SHOULD" in a note. Also, I'm personally against normative language about performance, becuase it's so hard to test. Maybe "do their best."
John Boyer: "Strongly encouraged"
Steven Pemberton: Yes.
John Boyer: I have a form that tests it with a 1000-node insert and a 2000-node insert and then measures whether the time doubles or quadruples.
Steven Pemberton: Runtime doesn't give you much guaratnee.
John Boyer: I used now() before and after. I can get a good idea.
Leigh Klotz: Two or three points isn't enough. You can't tell if you have a small K factor and are just below the exponential hockey stick. And if you pick N then tests we wrote 10 years ago would show up below the 10ms jitter in today's processors.
John Boyer: You can find a small interesting N and then move from there.
Leigh Klotz: But that implies a calibration step first to find N, which is dependent on processor speed.
Nick van: now() is stable and so will return the same value between refreshes.
John Boyer: That breaks the random() function for a quicksort.
Nick van: On the other hand if you're using now() in a calculation, when does the value get.
John Boyer: Now isn't the only function that has this volatility. It breaks most of my use cases for it.
Steven Pemberton: Functions with no parameters or different results with the same parameters are a problem in optimization. This isn't new.
John Boyer: These are volatile functions.
Steven Pemberton: Does XPath allow volatile functions?
John Boyer: Yes. Nick is proposing a rule for optimization.
Nick van: No, in XPath 2.0 you have to define the interval. XSLT chose the complete run of the transformation.
John Boyer: And that's for all functions?
Nick van: I think so. There is also per context.
John Boyer: All the other use cases I can think of for volatile functions are one where I can change the context.

Steven Pemberton: For the rest of the discussion, I'd prefer more of the group here. These are new functions which don't add functionality, just performance.
Nick van: Moreover, I think that most or even all cases, you can achieve the same performance with static analysis of the XPath expression.
John Boyer: I suppose you could. The processors I have access to don't and I would suspect a fair number aren't going to achieve that performance. There are some doing static analysis. That's great, but as an XForms author, if I want easy tools I can get guaranteed performance from this function. I can get a performance profile. It's really the difference between usable and not usable. For example, I have an 86-element phone list for my location site. With our @while to sort that list, if I do a simple sort it takes 5 seconds. Sorting by table column is totally out of the realm of acceptability. It's 2s with quicksort, and it's slow and infeasable. I can't afford that, especialyl server-side. It should be measured in milliseconds. It seems like we're a couple of functions away.
John Boyer: How can XSLTForms optimize these things?
Alain Couthures: No static analysis.
Nick van: XSLTForms could use Saxon.
Leigh Klotz: We could put it in a test case that does these operations that might be slow and verify correctness, and include a note that slowness is undesirable.
John Boyer: Then processor authors would have to fix their XPath implementations rather than use these functions.
Leigh Klotz: Can't you in your processor analyze the Xpath expressions and transform them, essentially doing static syntax?
John Boyer: That might take up all the time that the performance benefit would save.
Leigh Klotz: It might or it might not. Run Horn clauses on the AST of the XPath expressions.

Nick van: It sounds like your XPath engine isn't evolving as fast as others.
John Boyer: Adding extension functions is the defined way to add functions.
Nick van: It doesn't feel good to me that we're adding extensions so you can optimize your implementation.
Leigh Klotz: You can add the functions yourself, without group approval.
John Boyer: Then I have to use model/@functions and it's not interoperable.
Nick van: You could add custom function definitions.
John Boyer: It would have the same XPath limitations.
John Boyer: It's not a lot of work to consider using some extension functions if you're at this level of authoring (sort). While writing sort, I couldn't get xf:insert to be constant time in a certain case unless I added a dummy node to a list of nodes and later deleted the node. I'll be adding them as extension functions in our implementation, showing O(N log(N)) sort in XForms 2.0 and then it would work in all implementations.

Steven Pemberton: I hear what you're saying but I think we need more people to decide. I can't say either way yet.
John Boyer: It seems like a no-brainer.
Nick van: If our library gets too big it's hard for the author.
Leigh Klotz: What are the names of the functions?
Steven Pemberton: first-child, last-child, parent, next-sibling, previous-sibling
John Boyer: next-sibling::*[1] is next-sibling.
Leigh Klotz: And first-child is [1]?
John Boyer: Or node[(foo)] where foo is 1. So you can't analyze it.
Nick van: Then you can't use the function.
John Boyer: I can use choose.
Nick van: I can use readonly optimizations.
John Boyer: That wouldn't necessarily save.
John Boyer: I think these are useful alternative functions to have around. I don't see how these functions would cause a lot of confusion.

Leigh Klotz: Another possibility is for you to sell these functions to XPath 3.0 / XSLT 3.0 and we could backport them. If they're necessary we can't be the only ones who need them.
John Boyer: If another implementation has [1] optimized in our system we can as part of a conversion process, convert into functions, but that seems a self-centered
Leigh Klotz: That's exactly what static analysis is. Just do it when you load the form, not when you import it.
John Boyer: Yes, but then a form using [1] would perform well on our implementation but possibly not on others.
Leigh Klotz: Yes, to be blunt about it, that performance advantage is why someone would buy your system instead of another, as Steven pointed out in the W3C's position on performance being a competitive advantage.
John Boyer: Fair enough
Steven Pemberton: We'll continue this discussion when there are more people, but I won't be here next week.

* IRC Minutes


* Meeting Ends