Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net
Nick van den Bleeken, Inventive Designers
Doug Schepers, W3C
Roger Pérez, SATEC
Steven Pemberton, CWI/W3C
Susan Borgrink, Progeny
Keith Wells, IBM
John Boyer: Steven has a point
about namespaces.
Nick van: I think Steven has a good
point and they should not break backward compatibility and behave
differently on browsers that do and do not support
namespaces.
John Boyer: Does that cause namespaces
to be used in an unnatural way? I think in principle his point is a
good one.
John Boyer: Here is a purchase
order example. This version does not use XPath variables or named
binds.
Leigh Klotz: Where is this in the
agenda?
John Boyer: "Make progress on "Add
Model Item Properties to UI Level"
http://lists.w3.org/Archives/Public/public-forms/2008Mar/0013.html
<repeat name="order" nodeset="row">
<select1 name="Product"> ...
<input name="Quantity"> ...
<input name="Price"> ...
<output name="LineTotal" calculate="Price * Quantity"/>
</repeat>
<output name="Subtotal" calculate="sum(order/row/LineTotal)"/>
<output name="Tax" calculate="Subtotal * 0.07"/>
<output name="Total" calculate="Subtotal + Tax"/>
John Boyer: In the simplified syntax, the calculates would have $ as in < output calculate="$Price * $Quantity" />
Charlie Wiecha: What's the
semantics of the dollar?
John Boyer: Or, what's the canonical
form? If you look at the inputs that have names Quantity and Price,
roughly speaking, that creates a named bind in the canonical form
that binds to a Quantity element or Price element, and the the
$Quantity and $Price variables have a late binding that depends on
the context node that the XPath expression is evaluated in.
John Boyer: With <repeat
name="order" nodeset="row"> what does that make?
Mark Birbeck: I'd like to try to
clarify. Are these examples HTML with a bit of tweaking, onramp?
I'm co-opting the HTML name attribute to create a bind; it's not in
XForms itself.
John Boyer: I don't know whether that
matters. Look at
http://lists.w3.org/Archives/Public/public-forms/2008Mar/0013.html
in the canonical form; the name attributes in the simplified syntax
turn into refs in the canonical syntax. We define name as a
recognized attribute that is translated into something else, not a
name.
Mark Birbeck: To me the core next step
in resolving this is not the syntax, but working out whether we can
express what we want (the middle layer) using XForms. If we scroll
down to the canonical form, and use only nodeset and bind all the
way through, then the only problem is where output linetotal is
inside the repeat. So, are we happy that we can create a UI with
only binds, and no refs?
John Boyer: I need to know what bind
the repeat creates in order to get to the inner bind.
Erik Bruchez: I sent some binds to the
IRC; I thought we had figured that out already. It seems fairly
clear.
John Boyer: Then can you show what the
bind looks like.
Erik Bruchez: The bind for the order
is like you'd expect.
John Boyer: Nick's didn't look
right.
Mark Birbeck: The name= should be
id=.
Erik Bruchez: I used name because I
suggested we use name on bind for scoping, but we can work out the
examples with the id attribute as well. The name uses the name and
the nodeset and it just works out: <xforms:bind id="order"
nodeset="order">
John Boyer: And the repeat?
Erik Bruchez: <xforms:repeat
name="order" id="orderTable">
John Boyer: The repeat with the
simplified syntax.
Erik Bruchez: <xforms:repeat
bind="order" id="orderTable">
John Boyer: That's wrong; I want to
bind to the rows of the order.
Mark Birbeck: We need to crack the
canonical form first, and then do the simple syntax. It may involve
a new attribute. Our starting point is an HTML form with input and
output and maybe fieldset, as Dave Raggett
proposed.
Erik Bruchez: I think there is another
problem which is that we are still creating implicitly a data mode,
and the question is what we want it to look like. There is the
order and the child elements. If we want a structure with N order
elements at top level, without encapsulation, then the example
would just work.
John Boyer: You still need to name the
thing: <repeat name="order" nodeset="row"> The row is the
repeated element.
Mark Birbeck: As Mark said, you don't
want ref or nodeset in the UI because it makes it harder to move
things around. I agree. You don't have to think at all about the
implied data model that you are creating. You then have to think
about it when you introduce nodeset.
John Boyer: <repeat name="order"
thingIamRepeating="row">.
Nick van: So we have two new
attributes?
John Boyer: Tongue in cheek, we might
as well call it nodeset.
Erik Bruchez: ...
John Boyer: So there wouldn't be a
containing element?
Nick van: There's no need for
one.
Charlie Wiecha: ...
John Boyer: So the author has no way
to name the containing element.
Mark Birbeck: We're not saying how can
I write an XML document and that the author must be able to
generate an arbitrary XML document. It's much more akin to an HTML
form, where you get the data output that you have no control over:
name-value pairs. I see this as you generating a fairly standard
output that's useful. If you build the form and then build the
server side to process the name-value pairs, you can still do that,
but you have an XML document. Structure is OK but I'm not sure that
we need to start with an XML PO document and try to create
that.
John Boyer: I think we do. We see a
slightly different simplified syntax already from this discussion.
We need to settle on the simplified syntax and see what it means.
So I think we want repeat name="row".
Mark Birbeck: Where does the repeat
come from? In an HTML form, we would support repeat?
John Boyer: Possibly as a net new
element.
Mark Birbeck: We have repeat. I mean
that in our notion of simplification onramp, we say to start with
an HTML form, and then gradually add features to it to make it more
elaborate. So that first onramp part... you could even argue that
it doesn't need repeat, or something simple.
Erik Bruchez: One idea was that the
simplified syntax could implement the PO example. I think it's
trivial if you don't have strong requirements on the XML data
structure. You can calculate the sum for the lines and the total
for the lines. As you point out, HTML5 has repeat, and our
simplified syntax would be disappointing if it didn't.
Mark Birbeck: We've got repeat and
we're not talking about a language different from XForms. It's at
what point do you introduce it in as you build up? Our onramp form
authors will begin with an HTML form without repeat. Maybe
readonly, readwrite, data types, email, url, integer above 10, then
controls that combine (surname + last name). Then the fieldset
element might incorporate repeat, insert, delete, and
trigger.
Erik Bruchez: I see what you mean. I
remember Dave's example. We should consider this. If you have a
form that has the name attribute, instead of requiring nodeset, we
may as well do it. It fits well with the notion that we produce
binds.
Mark Birbeck: So we would put in an
XForms name attribute and use it from HTML.
John Boyer: Yes.
Erik Bruchez: I didn't think about
HTML. I was just thinking about a simpler syntax.
Mark Birbeck: Yes. I am trying to get
the exact HTML syntax. So if you start with an HTML form you can
start adding XForms features slowly. Name would have to work in an
XForms way for that to work.
Erik Bruchez: HTML4 doesn't have a
repeat anyway.
Charlie Wiecha: Can someone summarize
the new name attribute?
Mark Birbeck: It depends on which way
you look at it. In my model, it is shorthand for creating a binding
with the id and nodeset of the name and then the control binding to
that bind.
Charlie Wiecha: And in Erik's?
Mark Birbeck: It is a ref and gets
modified by the context.
Erik Bruchez: If we use ref instead of
bind then we can't calculate the total without using nodeset.
John Boyer: I didn't see any problem
in 0013 but I don't want to get stuck as I'm happy with the bind $
version. I think a way to translate is all we need. Is this it
http://lists.w3.org/Archives/Public/public-forms/2008Mar/0043.html
SIMPLIFIED:
<repeat name="row">
<select1 name="Product"> ...
<input name="Quantity"> ...
<input name="Price"> ...
<output name="LineTotal" calculate="$Price * $Quantity"/>
</repeat>
<output name="Subtotal" calculate="sum($LineTotal)"/>
<output name="Tax" calculate="$Subtotal * 0.07"/>
<output name="Total" calculate="$Subtotal + $Tax"/>
CANONICAL FORM:
<model>
<instance>
<data>
<row>
<Product>...
<Price>...
<Quantity>...
<LineTotal>...
</row>
<row>
<Product>...
<Price>...
<Quantity>...
<LineTotal>...
</row>
<Subtotal>...
<Tax>...
<LineTotal>...
</data>
</instance>
<bind id="row" nodeset="row">
<bind id="Product" nodeset="Product"/>
<bind id="Price" nodeset="Price"/>
<bind id="Quantity" nodeset="Quantity"/>
<bind id="LineTotal" nodeset="LineTotal" calculate="$Price * $Quantity/>
</bind>
<bind id="Subtotal" nodeset="Subtotal" calculate="sum($LineTotal)"/>
<bind id="Tax" nodeset="Tax" calculate="$Subtotal * 0.07"/>
<bind id="Total" nodeset="Total" calculate="$Subtotal + $Tax"/>
</model>
<repeat bind="row">
<select1 bind="Product"> ...
<input bind="Quantity"> ...
<input bind="Price"> ...
<output bind="LineTotal" calculate="$Price * $Quantity"/>
</repeat>
<output bind="Subtotal"/>
<output bind="Tax"/>
<output bind="Total"/>
Nick van: [irc] the only
problem with Erik's variables is that you can't refer
to all the LineTotal nodes only the one in the current row
John Boyer: I don't think that's true.
It refers to $LineTotal outside the repeat. The meaning of the
variables is decided depending on where the XPath expression is
located. That's why I wanted the canonical form. The calculate goes
on the bind that has id Subtotal. So the $LineTotal results in all
the line totals in the set of rows; it refers to an inner bind.
When you refer to an inner bind outside the bind, you get the union
of matches.
Erik Bruchez: You get the exact
behavior you're looking for in that example.
Nick van: [irc] I mean inside the
repeat. If you want to calculate for example the percentage of a
value compared to all the rows. I understand why it solves the PO
form.
Mark Birbeck: That's how it works now;
the only new bit is referring to the other nodeset.
John Boyer: Nick, look back at
calculate="$Price". That's an inner bind referring to the another
id in the same parent bind so it's a reference only to the
associated parent row element, not the union.
Erik Bruchez: You can't do everything
with this syntax.
Nick van: I have a better example. If
you have a lot of line totals and want to include a column that
gives percentage of complete sum (divide).
Erik Bruchez: You could do that with
an XForms output that is outside the repeat and refer to that. That
output would compute the total.
Nick van: It's a bit confusing.
John Boyer: I think it might be the
jumping-off point to understand XPath. I'm not sure. For
implementers, when you have a variable reference, does the XPath
engine give you the context node that the variable appears
in?
Erik Bruchez: You don't need to
because you know where your expression is.
John Boyer: What if you type
calculate="sum(../$LineTotal)"
Erik Bruchez: You can't do that.
Variables are in scope for that expression and they are the set of
name and value pairs, but the variable is not in context. We have a
stack and when the context changes, then we push the new context
information on the stack and that includes the variables.
John Boyer: [irc] Can't do, OK.
Variables values can be decided relative to context node of whole
expression, not context within expression
John Boyer: The only odd thing for
me is this: take the simplified syntax with $ and say that implies
0043 canonical form. Then take out the $ and it still works in the
canonical form.
Erik Bruchez: Or leave them there; you
may have to slightly work out on the dependency graph, as the XPath
engine will tell you the variables. So you don't need to take out
the $. You don't have to worry about ../ or context.
Charlie Wiecha: Why isn't the context
wrong for the line total example?
John Boyer: It's wrong with the $ out;
you'd have to say row/LineTotal instead of LineTotal, but it's
otherwise identical.
Nick van: Is it because of the rule
that the nodeset changes from one rule to all whether you are
inside or outside the bind? I'm not used to that yet.
Erik Bruchez: For when you remove the
$ it works are do you mean the email you sent? The grand total
needs a context attribute.
John Boyer: Replace $LineTotal with
row/LineTotal.
Nick van: You need a nested calculate
with context=".." and then it's OK.
John Boyer: If you start with
<output name="Subtotal" calculate="sum($LineTotal)"/> in 0043
and someone "forgot" the $ why can't I type this instead:
<output name="Subtotal"
calculate="sum(row/LineTotal)"/>
Nick van: You need the trick.
John Boyer: The ../. I see, name
doesn't change the evaluation context, but ref does.
Nick van: That's what I asked you last
week.
John Boyer: The $ syntax allows us to
define a change of context as an implicit behavior of the
processor.
Erik Bruchez: Yes. It saves a lot,
especially in the specification.
Mark Birbeck: To loop back to
something Erik said last week: one of Erik's problem with $ was
that he wanted to reserve it for variables, and then maybe this is
what variables are. But Erik said variables are locally scoped and
in context. So one twist is that where you've created binds in
0043, if you had each bind created next to the control that it was
caused by, then that output <output bind="LineTotal"
calculate="$Price * $Quantity"/> would be locally scoped.
Nick van: It has to be available
outside the scope though.
Mark Birbeck: Yes, that's true.
Erik Bruchez: I haven't yet reconciled
bind variables and scoped variables. The bind provides the name but
also points to the node for MIPs. Variables in XPath and other W3C
recommendations are defined as variables with name and values with
allowed XPath content. I have very lukewarm feelings to say that
bind is a variable; if we were to extend bind to hold strings, then
why would I use bind when I want to use variable?
Nick van: I wasn't complaining about
bind, and I would about using variable, if you define it once, the
value stays the same. Here we have a different situation and the
bind declares two variables; one inside repeat and another
outside.
John Boyer: [irc] <output
name="Subtotal" calculate="sum($LineTotal)"/>
John Boyer: [irc] <output
name="Subtotal" calculate="sum(row/LineTotal)"/>
Mark Birbeck: ...
John Boyer: What if you want to refer
to the outer line total from inside the repeat?
Mark Birbeck: You have to create some
kind of global subtotal.
Nick van: That's a bit limiting.
Erik Bruchez: So you could do
...
John Boyer: So you can escape dollar
syntax when you need to because the canonical representation is
defined.
Nick van: Then why do we need
attribute name instead of ref?
John Boyer: In 0043 the name implies a
bind and a UI control with a bind instead of a ref.
Mark Birbeck: That's how we first
implemented the XForms processor, with everything creating a bind.
The implementation is starting to look straightforward. We need to
say something about the evaluation context. If your evaluation
context is given to you by a bind statement, then the variable
bindings come from that bind statement context.
Erik Bruchez: That's not quite
correct; in a LineTotal before repeat, all the variables would be
in scope. You do see those variables as well.
Nick van: That's a bit of a
problem.
John Boyer: We have four or five minutes left.
John Boyer: Is 15 minutes later for
this call reasonable? Is there anybody who feels it's a
problem?
Charlie Wiecha: It's OK for me.
Nick van: It's fine for me. But I have
to leave at 6:30.
Steven Pemberton: [irc] I have trouble
staying until 18:30. 18:15 is already hard.
John Boyer: I thought Mark and Steven
would appreciate not overlapping XHTML2.
Mark Birbeck: I'd prefer to solve it.
It's OK for me, but maybe for Nick and Steven.
John Boyer: In Steven's case it's more
advantageous to have Steven for the first 15 than the last
15.
Steven Pemberton: I think 90 minutes
is important but the overlap is the problem; you should do your
best. It's troublesome to stay after 6.
John Boyer: It would be good to get
you in the first 15 minutes of the call and we could understand
leaving early. We lose 15 minutes either way but as Team Contact we
could have you earlier.
Mark Birbeck: I could also drop off
the XHTML2 call 15 minutes earlier.
Steven Pemberton: We could ask the
XHTML2 group to move a quarter of an hour earlier.
John Boyer: Can you ask?
Steven Pemberton: I'll ask. We moved
it later and it was a problem for people on the west coast.
John Boyer: Steven, please look at the starred issues in the agenda. Let's continue discussing http://lists.w3.org/Archives/Public/public-forms/2008Mar/0043.html and see if we can go with it.