Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Steven Pemberton, CWI/W3C
Uli Lissé, DreamLabs
Keith Wells, IBM
Nick van den Bleeken, Inventive Designers
John Boyer: ODF has XForms support, but some of it is spotty, such as the lack of repeat and the support for model item properties on UI bindings. I'm hoping to file "last call" comments on ODF 1.2.
John Boyer: I can't make the May 7
telecon chair.
Steven Pemberton: Nor can I, as I am
at XTech.
John Boyer: Can someone else serve as
chair?
Nick van: [irc] I am available so I
can try.
John Boyer: I can provide the agenda
for you.
John Boyer: There's no need to consolidate Mark Birbeck's action items; just mark them all done when he does them. I'd like to encourage everyone to get through one thing done.
Action 2008-04-23.1: John Boye to address Typo in xforms-submit-done http://lists.w3.org/Archives/Public/public-forms/2008Apr/0088.html
Nick van: The problem is that is
with a couple of binds and predicates that select some of those
nodes. I don't think it can be done according to the spec. If you
have a dependency on ../item[] then you have a dependency on all
the items.
John Boyer: That is correct; we say
that, yes. If I understand correctly, using a,b,c for id; which of
these binds breaks?
Nick van: All of them because they all
have a nodeset item with @id=something and the calculate uses other
items with other ids.
John Boyer: Then just the first one is
unable to work?
Nick van: Yes because there is another
bind that does a calculate based on an item.
John Boyer: If you just looked at the
first one by itself?
Nick van: I think it would be a
circular dependency.
John Boyer: So you're saying the
nodeset identifies a particular item, but along the way the
predicates are winnowing down to a particular item in both cases,
but the expressions are dependent on all the items, including the
one identified by the nodeset. We take out self-references
automatically.
Nick van: That will work. But if you
have two binds?
John Boyer: Your second bind binds
without a calculate so there is no problem. I see; on the third
bind down, the reference list lists all the items, not just 4, 5,
and 6. So the third bind b-23 is dependent on a set of things that
includes b-21, which depends by b-23. So we don't know which order
to run those two calculates in.
Nick van: My assumption was that it
depends on all the item elements.
John Boyer: http://www.w3.org/TR/xforms11/#expr-dependencies
A node is selected by matching an XPath node-test or a function
call. A node-test includes the name-test. ... So we claim in
rigorous terms that the reference list produced by this calculate
will include all the items, not just the ones that match the
predicate. I think we were in Madrid when we talked about
specifying this more fully in the spec. I think my prior
understanding had been that you had to match both the node test and
the predicate, but the group majority wanted to be on node-test
only.
Nick van: I remember that but I don't
recall what we resolved then.
John Boyer: We say it is referenced
even if a filter subsequently excludes it. For better or worse, we
are now clear on the subject.
Nick van: I'm not sure why.
John Boyer: http://www.w3.org/TR/xforms11/#expr-dependencies
John Boyer: http://www.w3.org/TR/xpath#NT-NodeTest
John Boyer: http://www.w3.org/TR/xpath#NT-Step
Steven Pemberton: link to
example?
John Boyer: http://www.w3.org/TR/xforms11/#expr-dependencies
John Boyer: So, Nick, can you take an
action to explain why a node is considered to be matched when it
passes the node test and not just the predicate is matched for
bind?
Leigh Klotz: Isn't is to allow the
bind to match a different node if the predicate condition changes,
such as if you setvalue @id in one of these examples?
John Boyer: Yes, that must be
it.
Erik Bruchez: I think it's time for
someone to write a new article about dependencies.
John Boyer: Do we still need the
action item or is that good enough?
Nick van: I'm comfortable. I can write
a note to explain it.
John Boyer: I think it would be
useful.
Nick van: minutes madrid: http://www.w3.org/2007/09/12-forms-minutes.html,
http://www.w3.org/2007/09/12-forms-minutes.html,
http://www.w3.org/2007/09/12-forms-minutes.html,
Action 2008-04-23.2: Nick van den Bleeken to propose note to for http://www.w3.org/TR/xforms11/#expr-dependencies to explain rationale for bind causing dependencies on node-test and predicate conditions.
John Boyer: Is anyone reviewing
this?
Steven Pemberton: I am for XHTML2, by
June 30th.
John Boyer: I think Nick should file
his comment independently. Steven will you look at with an eye
towards XForms submission.
Steven Pemberton: Yes, any URIs that
might be in XHTML2 or XForms.
John Boyer: We need to keep the
conversation going here.
Nick van: I want to respond but I need
to coordinate with Mark on elements and attributes.
John Boyer: I think the disagreement
is whether a core XForms processor should respond to the HTML brand
of syntax. In the tag soup example, no, but if you had well-formed
XML, would we expect an XForms processor to do that? Maybe RFC-2119
with May or Should instead of Must. Or it may lie in a module,
which an XForms processor May or Should support. Factoring out that
concern, I think it's relevant that if a fieldset used a name
attribute, it might be something we'd be suggesting as allowing
that fieldset to participate in the XForms processing model as if
it were a group.
Nick van: We didn't discuss WebForms
2.0 proposal. Do we need to support those elements?
John Boyer: Part of the issue there is
that at the broader architectural level, one of the principles I
was trying to get across is that all of the efforts to improve HTML
going forward should adopt the principle that features that people
would like to have that are already expressed in a prior
recommendation of the W3C, that those prior recommendations should
take priority on how to make that feature. An XForms way of doing
that feature should take priority over the ideas that are expressed
in Web Forms 2.0 over repetition. As dog food, there is our taking
a step in a module in XForms or Core XForms such as fieldset and
the form tag, because they have precedence from HTML4. Otherwise,
there is a proliferation of different ways of trying to express the
same idea and trying to wire them all into one processing model
becomes more difficult.
Nick van: ...
John Boyer: We should ask how Web
Forms 2.0 tables and repetition map into a recognized data layer,
with their syntax?
John Boyer: What happens when the
user wants to take the next step with XForms; we are trying to
create an onramp. The first step seems to be the full-streamlined
syntax with only UI controls and attributes. What's the next step?
Do we want form authors to be able to express their own instance
data? binds? There's a precedent expressed by HTML, with the form
tag. It seems to be a useful container. We don't have a single
container that is one UI and one set of form controls.
Leigh Klotz: I was hoping some of the
recursive composition stuff that Charlie was doing would be out for
us to explore.
Nick van: You can't have a wrapping
element for your model if you have them separate for the UI.
Steven Pemberton: [irc] I don't see
the need for wrapping controls quite honestly
Nick van: Interleaved in the
markup
Steven Pemberton: [irc] Yes, a mashup
or similar
John Boyer: How would you make a form
as a component?
Leigh Klotz: Isn't that was the RAC
stuff was?
John Boyer: XAC. It's more
complicated.
Leigh Klotz: It's hard to evaluate
without knowing what XAC solves.
John Boyer: Their work is about saying
what to do with the net results of that component.
Leigh Klotz: Raman and I proposed a
string language of defcomponent and component, and it got thrown
out as being too hard to describe, very early on. I don't think
that we can just say that a form tag works without saying how it
works.
John Boyer: Portal software does it
already. We don't have to say how. It's useful anyway.
Nick van: That can be done by markup.
Why do we need it?
John Boyer: Our language?
Nick van: The host language.
John Boyer: That bothers me; for the
sake of a single tag, we don't have completeness.
Nick van: There was a last-call
comment that we needed a wrapping element and we decided we
didn't.
John Boyer: Not for XForms 1.1. But
XForms 1.2 is for appealing to existing web authors.
Nick van: What's easier than just
dropping the element?
John Boyer: When you try to use our
technology in a web application context with two portals, how do
you conveniently say that all these things are in the portlet on
the left and all of these things are in the portlet on the
right.
Leigh Klotz: You just want something
for scoping?
John Boyer: Easy scoping. It's like
aspect orientation. You have a cross-cutting concern that you have
to go into every control and add the model.
Nick van: You have the same problem
with bind ids.
Erik Bruchez: The portals have this
same problem. They prefix every single id in forms to avoid
conflict. They say use an API to get a portlet prefix for the ids.
If you use JSP, you have to do it everywhere.
Erik Bruchez: There are multiple
strategies for translating XForms to HTML4, but that seems
irrelevant. From the form authors perspective, do you want a form
element for grouping?
Nick van: If they want to submit to
multiple places, they can put the submission on their submit
component instead of using JavaScript.
John Boyer: Or new attributes like
XForms submission, directly on their submit. That should imply a
particular XForms submissions as well.
Nick van: Or non-HTML authors who want
to override XForms submission attributes on the submit
control?
John Boyer: Absolutely. It's like the
calculate attribute, in core XForms. There seem to be lots of cases
where we're elaborating attributes instead of using elements. It's
the same idea in the case of the form tag, though inside out. It
turns out there are very few things we have to add to the InfoSet
level. What we're really trying to distinguish is which of the
web-author streamlined syntax measures do we really want to
incorporate into XForms, and which do we want to be only available
to web authors.
Nick van: In my opinion, only the ones
that add functionality to the people who don't know HTML4.
John Boyer: So let's get rid of the
spelling "form" for a minute. What if the model tag could be a
container, not just binds and instances and submissions but also
the UI to present it. Might that be useful? You could have it a
separate file and refer to it.
Nick van: A form without a host
language would be useful for us.
John Boyer: The host language could
pull in the whole bucket all at the same time.
Leigh Klotz: Don't you mean just a
minimal host language that borrows from HTML4 forms and gives you
styling from HTML?
John Boyer: No, not a minimal host
language. I could use it in XFDL.
Nick van: We use a minimal host
language in our mobile stuff.
John Boyer: Why can't you have a model
in the body of HTML? As you start to get into components that's
going to happen to us. Modulo the model issue, if we want to
incrementally introduce elements of XForms to web authors, how are
they going to create the association between their UI controls and
those extra elements? bind?
Nick van: Or write "model".
John Boyer: Does that model then take
over for the implied model of the UI controls?
Nick van: It is the same issue with an
instance.
Erik Bruchez: We use models to
group functionality. We don't have a mapping between a model and
controls.
John Boyer: The form tag may be like a
fieldset, a module for HTML authors that maps that form tag onto
the XForms InfoSet so that HTML4 authors can get access to XForms
functionality. Or maybe we don't have to translate it. We can
continue this thread on the list: what ends up in Core XForms and
what is part of an HTML profile? Maybe all we need is an HTML
profile and calling it XForms 1.2 is the wrong answer.
Nick van: XForms 1.2 is also making
form authoring easier for non-HTML authors.
John Boyer: Perhaps. We need to figure
out which things in the HTML profile are useful for all authors,
starting from the HTML author and working out. As you point out,
how many attributes from input are actually useful?