Leigh Klotz, Xerox (minutes)
John Boyer, IBM
Steven Pemberton, CWI (chair)
Alain Couthures, AgenceXML
Nick van den Bleeken, Inventive Designers
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 1.2.3.5.
Steven Pemberton: Good idea.
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.