Alain Couthures, AgenceXML
John Boyer, IBM
Steven Pemberton, CWI/W3C (chair)
Philip Fennell, MarkLogic
Erik Bruchez, Orbeon
Leigh Klotz, Xerox (minutes)
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.
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.
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.
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.
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.