Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net [irc only]
Nick van den Bleeken
Roger Pérez, SATEC
Doug Schepers, W3C
Steven Pemberton, CWI/W3C
Susan Borgrink, Progeny
Keith Wells, IBM
Uli Lissé, DreamLabs
John Boyer: Kenneth sent
regrets.
Leigh Klotz: Once we get the
implementation report, I'll put the dates in and we'll re-do the
pub rules check.
Steven Pemberton: I spoke to Mark
Seaborne and he said the action item was passed on to him.
John Boyer: I'll talk to Mark.
John Boyer: Let's get each person
with more than 10 to fix one. Mark Birbeck isn't available. I'll
commit to doing the "fix the schema issue" as I'm already doing the
"purchase order example." Leigh is next.
Leigh Klotz: What are the two CSS
ones?
John Boyer: The first one is Appendix
G for CSS3 namespace module. The second is to update to reflect in
CSS examples.
John Boyer: So you'll do Action
2008-01-16.1 this week?
Leigh Klotz: I'll get started and when
I have parts I don't understand I'll send a note to the list.
John Boyer: Steven, there may still be
some triage work. So could you do that? There are some about
resolved CR items. So send the reference numbers in the right hand
column to Nick.
John Boyer: We talked about this last week; we decided not to adjust 1.1 but would do this in a future issue.
Action 2008-04-2.1: John Boyer to write up spec-ready text proposal for 1.2 for Behavior of replace=text for submissions that retrieve non-text as in http://lists.w3.org/Archives/Public/public-forms/2008Mar/0079.html
Erik Bruchez: I had a quick glance
at it and may be wrong. It looks like a standard way of
implementing use cases, as there are multiple ways of doing some
things. If you follow the patterns in the spec, then the hope is
that you'll achieve higher interoperability among tools that
process XML schemas, so you can create XML documents and other
bindings from the Schemas.
John Boyer: It sounds like they're
trying to figure out ways to get from Schema to other things. They
don't mention XForms, or XML. The spec just lists XPath
patterns.
Uli Lissé: [irc] in the java
world there are many databinding tools. they are often used in web
services stacks like axis. the schema is used to generate a class
tree implementing structure and validation rules prescribed by a
schema.
John Boyer: It seems like it might be
relevant to us; we should decide whether we have any comments we
need to make about the spec. Is anyone involved or interested in
automatic generation of XForms?
Erik Bruchez: Maybe.
John Boyer: Please get back to us on
this.
Steven Pemberton: I can review this
for XForms and XHTML2. I anticipate no problems at all as it's just
errata republished as a PER.
John Boyer: Where does this
apply?
Steven Pemberton: Anywhere there are
urls.
John Boyer: Any application to
instance data nodes of type anyURI?
Erik Bruchez: We discussed this at
some point, with xf:load and whether we decided not to do xml:base
resolution for instance data.
Nick van: [irc] I noticed that they
completely rewritten '3.1 URI Reference Encoding and Escaping'
Action 2008-04-2.2: Steven Pemberton to review XML Base PER June 30 as in http://lists.w3.org/Archives/Public/public-forms/2008Mar/0087.html
John Boyer: We are getting closure
to the simplified synstax
John Boyer: I'd like to continue
pushing forward on engagement with the task force.
John Boyer: I think our simplified
syntax is quite a bit shorter than canonical form.
John Boyer: Is anyone uncomfortable
with using the name attribute to imply we want the special behavior
of a set of binds? That's #1. For #2, there is a naming convention
that allows you to refer to the names that have been typed directly
within calculate expressions. So there's a naming structure in the
binds that and there's an implied context=".." so that
calculates being applied to these UI controls are applied relative
to the in-scope evaluation context node, as opposed to the node
that might be indicated by the UI binding that the name attribute
implies. That makes simplified syntax without $ work. Then #3 says
that binds will be addressable in calculations by using the name
that is the name of the variable, so that someone can do $ instead
of / separated.
Mark Birbeck: [irc] Hi everyone. Sorry
I can't make the call. John has mentioned in a separate window that
you might be close to a resolution on the simplified syntax
discussion, and I'd like to add my vote if that's the case. My
position is still that I favour @name mapping to a
flat model. I feel this 'flat model' is best achieved
by mapping to <bind; statements, and further that a convenient
way to refer to those binds is via the dollar syntax. But note that
I am not therefore saying we MUST use the dollar syntax to address
the binds, or that binds must represent variables. It just seems to
me that the whole package of "@name -> <bind> -> named
variable -> reference via $x" is pretty coherent, consistent and
ultimately very useful in many different ways, not just in the
simplified syntax.
Uli Lissé: John, did you
receive my reply?
Nick van: [irc]
http://lists.w3.org/Archives/Public/public-forms/2008Apr/0006.html
John Boyer: Uli?
Uli Lissé: I think the variable
syntax is not needed and complicates things. I have a feeling, not
hard data, that it will collide with real XPath variables.
Charlie Wiecha: That's behind my
question, too. I remember a couple of weeks ago. Once we introduce
formal XPath variables, are we sure we can do it. See Mark's
comments in IRC as well.
Nick van: I believe the binds are like
parameters that you put in toplevel in your XSLT. I don't think
there are problems.
Erik Bruchez: Nick is saying there are
variables in other languages you can declare XPath variables. I
don't think using bind to declare variables is a problem. The
bigger problem is, I don't know, elegance, or syntactic
consistency. It may look awkward to people that all binds
implicitly declare variables. I suggested last week that we
introduce a name attribute on bind. Then variables would be
declared by bind only when you have a name attribute. That would
preclude confusion.
John Boyer: Mark, why might we need
both ways?
Mark Birbeck: [joins] My main argument
is the one I wrote up on the list, of having a flat data model.
When I first started talking about the simplified syntax in Venice,
the main onramp I wanted to promote was a flat data model for the
author. I'm not totally convinced that using context=".." to hide
some of the subtleties of hierarchy in XPath is equivalent to
creating a flat data model. I mean, that you can refer to something
by name and no matter where you are in the UI it will still be that
same piece of data. Because we're constructing the data to mirror
the UI we don't see that data model, but when you start merging
that with your on data, things start to change. So my feeling is
that the ability to refer to anything from anywhere within the UI
is quite important.
Charlie Wiecha: So the $ syntax would
let you ignore the hierarchy? ...
Mark Birbeck: Yes. There was an
example before that just worked, but if you then wrap a group
around it, and merge the simplified syntax with more advanced
XForms concepts, then it starts to break down. So that's what I'm
getting at. If you say $subtotal you should be able to move that
around and still get the subtotal. The example I gave was the
summary page of a shopping cart, with $total. Putting that in many
positions within the form, not just in the one place we have,
requires a flat model.
John Boyer: Not quite a flat model,
but the $ are making the calculations more immune to changes of
structure in the UI because the variables will automatically work
out their context.
Uli Lissé: You don't need the $
syntax for that.
John Boyer: In your mail, Uli, the
output for the total, should be sum row/lineTotal.
Uli Lissé: No, it's by intent.
It's the same as with $ but not with $. The generated line indeed
has that. There is some parsed-re-writing here.
Nick van: [irc] It becomes hard to
identify what path-steps need to be re-written.
Mark Birbeck: Uh
John Boyer: That makes it harder to
automate re-writing to canonical form.
Uli Lissé: Really? In what
case?
John Boyer: In this case, you would
have to write XSLT to parse the expression.
Uli Lissé: Does it have to be
XSLT?
Nick van: It is still a path
expression if it is just one atom. So it's hard to find.
Uli Lissé: You have to re-write
any expression that occurs on a form control with a name attribute.
All path-like constructs are like $ syntax, but without the $. You
resolve to another control with that name and you get a
nodeset.
Nick van: But you can't then use more
complicated XPath in those expressions. In my opinion, you can use
variables and XPath expressions mixed.
Uli Lissé: Why would you do
that?
Mark Birbeck: So you're creating a new
path language: when the name is present you parse them one way, and
when not present, you parse them another.
Uli Lissé: Yes.
John Boyer: So far we've said that the
expressions are preserved, but moved in context to give them
different meaning. It's a black box.
Uli Lissé: The calculate
expression in your proposal, you have ... so it's not a black
box.
John Boyer: I mean, in the canonical
form, it doesn't matter which of the two you started with; there is
a set of binds and whichever of the calculates appeared in the
simple syntax is the one that is copied and it will still
work.
Nick van: John is using XPath. You're
using the Uli expression language instead of XPath.
Uli Lissé: It's XPath but the
instance data isn't there.
Nick van: It isn't the XPath
syntax.
Uli Lissé: It's done using
static analysis. You'd have to parse with XPath and re-write.
John Boyer: The proposal we're trying
to get to is that you don't have to use the $ syntax, but it has
some benefits if you use it.
Leigh Klotz: That emergent aspect of
this proposal bothers me, that if you have a $ and it works the
same expression without $ works mostly.
Mark Birbeck: Any syntax that embeds
XPath is going to have this problem, and it's just a question of
when the author needs to learn the level of complexity.
Leigh Klotz: I'm just concerned that
they shouldn't have to make the leap because of a single-character
typo.
Mark Birbeck: Ulrich, I think if we
wanted another expression language we would need simply use
Javascript.
John Boyer: ...
Uli Lissé: But it is just
XPath.
John Boyer: XPath takes only one node
as a context node, not four or five. The expression sum/lineTotal
is an XPath expression.
Mark Birbeck: It conforms to the XPath
syntax.
John Boyer: It isn't XPath because of
the evaluation. It would need a context nodeset to evaluate, which
XPath doesn't support.
Uli Lissé: It's an XPath
expression, but without the same meaning.
Nick van: It's not XPath then.
Mark Birbeck: You need more
information than would normally be given; therefore it is more than
an XPath parser. THe fact that the syntax is the same is neither
here nor there.
John Boyer: It syntactically matches
the XPath expr production but it doesn't evaluate.
Uli Lissé: It just depends on
the evaluation context.
John Boyer: Which row do you plug into
the evaluation context for the summation?
Nick van: [irc] it becomes hard to
identify what path-steps needs to be rewritten
sum(LineTotal)*AnotherContrl. if you evaluate this
expression the LineTotal path expression needs to evaluated against
all row elements. the AnotherContrl path needs to be evaluated to
another context.
John Boyer: You have to feed in a
context node, not a nodeset.
Nick van: I think you can do that in
XPath 2.0.
Erik Bruchez: You have context item
and position. I think it's the same, but it's a context item, which
can be an integer. So it's the same as XPath 1.0.
Nick van: The example I just gave
breaks because you need two contexts. That's where it breaks.
Uli Lissé: I don't want to
discuss XPath syntax in detail, but I want to discuss $ syntax. I
just don't think it's needed.
Erik Bruchez: I suggested the $
syntax. But I also proposed a function control(xyz).
We could do bind as well. But I'm not sure what bind tells someone
who is new to XForms.
John Boyer: I don't want to type very
much. The extra $ is as much as I type. If they want to add extra
hierarchy and that changes the naming conventions for things, the
know they'll have to put extra slashes because their naming
convention changes. Those people won't use $. Then there's the
people who will use $ and we should focus on them. They'll get
further along before they have to think about UI hierarchy and
uniqueness of names.
Erik Bruchez: I like the variable
syntax. ...
John Boyer: ...
Erik Bruchez: That's one of the
reasons I had for this proposal. We shouldn't use ids for this;
that's for unique references. In the model, we have scope, and id
is document unique. That's a separate problem.
John Boyer: I think everyone agrees
that switching over to bind name would help. That means we don't
have to do unions of binds as well.
John Boyer: It seems we need a proposal that can go to full-out XPath and we have that. The $ syntax provides a flatter namespace for a longer period of time for a larger set of users and they can go on longer before they discover they need to use XPath, and they still don't have to deal with canonical XForms, just that the UI hierarchy is creating hierarchy.
Leigh Klotz: This is a secondary
point, but what's the difference between <xf:bind name="foo"
calculate="123"/> and <xf:variable name="foo" select="123"
/>.
John Boyer: You can nest binds, but
not variables.
Erik Bruchez: Our binds hold only
nodesets.
Mark Birbeck: I'm not sure what we're
discussing here. binds are not variables. But that doesn't matter.
When you get to the XPath expression.
Leigh Klotz: Yes, the XPath syntax is
the same. I'm asking about what the canonical form is, and whether
it results in a haired-up bind or whether we are really just making
an equivalent to xsl:variable here.
John Boyer: There's the nesting
argument.
Erik Bruchez: If you did this with
variables you have to redo it all the machinery of bind.
John Boyer: Take the binds that are in
part 5 of 97 and try to write the variables.
http://lists.w3.org/Archives/Public/public-forms/2008Mar/0097.html
Leigh Klotz: So they change in
context?
Nick van: They are global variables
but change in scope.
John Boyer: So we're creating global
variables that change according to where they are referred
to.
Leigh Klotz: OK I'm convinced.
John Boyer: I'm not sure how close
we are. We may need an extra telecon.
Mark Birbeck: Is it worth a straw poll
to see how close we are? If there are a couple of people opposed to
it, then we still have to do stuff. If everybody is opposed, I
don't know.
John Boyer: It's a pretty long and
exhaustive email.
Leigh Klotz: That message doesn't
include the change to bind/@name.
John Boyer: Right. But a lot of the
details are worked out.
Leigh Klotz: Mark, where do you
stand now on the hierarchy?
Mark Birbeck: This is the proposal I
had in mind in Venice but it's better. I hadn't worked through the
repeat stuff, and my idea fell apart. Also, the point of Erik's on
name rather than bind is a big improvement, which is better than my
original proposal. I came on the call because everybody was
rejecting the $ syntax. I'm not totally wedded to it, I haven't
been able to come up with anything better. Most of the AJAX
libraries use $ to represent DOM references. It won't look funny
and it gives a nice route in to XForms.
John Boyer: Ok, we seem, to be doing a straw poll on http://lists.w3.org/Archives/Public/public-forms/2008Mar/0097.html plus the name attribute for bind.
Charlie Wiecha: [irc] i was
originally opposed to having both $ and non-$ notation, but now
like the ability to have a "flat" space of names, so I'm +1
Nick van: [irc] Since a couple of
weeks, I'm personally convinced that the $ proposal is good
proposal for me. So for me we can start working on the details on a
separate call
John Boyer: [irc] I like the dollar
syntax as an easier way for people to get started and go for longer
with a "flat space" understanding of the world, and then they can
scale up to full XPath without too much pain.
Leigh Klotz: [irc] +1
Mark Birbeck: +1
Keith Wells: Keith says move forward
+1
Uli Lissé: +/-0
Steven Pemberton: +0
Charlie Wiecha: I'm curious about
the folks who are expressing 0. Steven?
Steven Pemberton: It's with the
background of the idea. I'm not convinced we need to answer this.
So, carry on.
Mark Birbeck: I think it's a shame to
see simplification in this light. XForms should be sweeping all
before it. It needs an onramp.
John Boyer: I've been doing this since
1993 and if we have a way to usher the on-the-glass designers in to
MVC it is helpful. The $ stuff for binds, rebuild separated out and
the bind function, are all coming out of the core
improvements.
Mark Birbeck: The sweet spot is that
the model is sitting there waiting for the author. Our stuff looks
like it's on the glass, but you have the entire power of a model
behind the scenes.
John Boyer: And this checks off the
"make something simpler that maps to what we have" so it is
substantial.
Charlie Wiecha: I like the idea of
thinking of this as a benefit to XForms as well.
John Boyer: I like it and hope others
will start liking it. Resolved?
Resolution 2008-04-2.1: Proceed to spec ready text on simplified syntax and canonical form expressed in http://lists.w3.org/Archives/Public/public-forms/2008Mar/0097.html plus name attr on bind as way to create variables
Action 2008-04-2.3: John Boyer to provide spec ready text on simplified syntax and canonical form expressed in http://lists.w3.org/Archives/Public/public-forms/2008Mar/0097.html plus name attr on bind as way to create variables