Blake Jones, ViewPlus Technologies
Charlie Wiecha, IBM
David Landwehr, PicoForms
Erik Bruchez, Orbeon
John Boyer, IBM (co-chair)
Joern Turner, DreamLabs
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net
Nick van den Bleeken, Inventive Designers
Steven Pemberton, W3C/CWI (co-chair)
Dave Raggett, W3C/Volantis
John Boyer: My voice is going;
Steven can you chair?
Steven Pemberton: OK. I gave a talk on
XForms at Apachecon today, and the evolution of programming
languages.
Steven Pemberton: Call next week?
It's the web conference. John will you be at the web
conference?
John Boyer: Yes.
Steven Pemberton: So we have a call
next week. I understand it is -20C in Banff.
Charlie Wiecha: Can you post the
link again? Our internal page still points to Palo Alto.
Leigh Klotz: It also still points to
the old charter.
Steven Pemberton: http://www.w3.org/MarkUp/Forms/Group/
is the old page. It's now http://www.w3.org/MarkUp/Forms/Group/
Charlie Wiecha: That's the public
page.
Steven Pemberton: We don't have an
internal page anymore.
Nick van: [irc] http://www.w3.org/MarkUp/Forms/2007/06/ftf/
Steven Pemberton: Please fill in the form, ASAP.
Steven Pemberton: Anything to
say?
John Boyer: I'm working on it. I have
starred the things we need to talk about.
Leigh Klotz: I need to do the
implementation report. I will mail the PR to the folks at
PicoForms.
Steven Pemberton: If you can get this
done before next week I have a meeting with Steve Bratt to schedule
a transition call.
Leigh Klotz: I will take the XForms
1.0 one, remove the Schema stuff, change the name.
Steven Pemberton: And add the
photo?
Leigh Klotz: Steve Bratt didn't like
the photo before.
Steven Pemberton: OK, so no
photo.
Leigh Klotz: Just letting you
know.
John Boyer: I spoke to Dave Megginson and he was hopeful.
John Boyer: I think Dave Raggett won't be
involved because he's chairing a new group. We need some people to
participate in this task force. This is for XForms Transitional and
provide feedback on whatever that turns into. Should we poll for
interest?
Steven Pemberton: Sure.
John Boyer: Dan Connolly has done
something similar for the HTML WG and 6 or 7 people have expressed
interest.
Steven Pemberton: I'll look at his
questionnaire and make one.
John Boyer: His is part of a bigger
one; I'll send you sample text.
Action 2007-05-2.1: John Boyer to send sample text for HTML WG Joint Task Force interest to Steven Pemberton.
Action 2007-05-2.2: Steven Pemberton to create questionnaire for interest in HTML WG Joint Task Force.
Steven Pemberton: It's not a last
call issue because it was sent to www-forms.
John Boyer: I'm amenable to discussing
it now or later. I think this did end up becoming a last-call
comment; I'm not sure. It seemed a bit of an inconvenience but
here's something you can't do.
Leigh Klotz: So current doesn't work
here?
Mark Birbeck: No.
John Boyer: That's the output of the
ref,not the context of the ref.
Mark Birbeck: There's loads of use
cases where you have to use the index of the repeat.
John Boyer: Is that a
workaround?
Mark Birbeck: Yes. The trigger changes
the current index of the repeat, if you believe the action handler
is run after the index is set.
Leigh Klotz: The same happens with
labels inside of trigger with ref all inside of repeat. You can't
get it back with that hack.
Erik Bruchez: [irc] We have
implemented such a context function
Erik Bruchez: [irc] Variables would
also solve this problem
Nick van: [irc] an action with a while
on it, but then it is a repeat again.
Erik Bruchez: [irc] context() should
could rather take the id of the enclosing element
Mark Birbeck: Nor with this proposal.
All you've done is defer the problem. Unless you have a context
function, there
Leigh Klotz: Some can be done by
static analysis and repeating the expression, but repeat can't. You
may not need the arbitrary context.
Mark Birbeck: And action handlers.
Steven Pemberton: So what do we
do?
John Boyer: We give the index solution
for now, and say that we have added the general case to our futures
list (e.g. Leigh's issue).
Steven Pemberton: OK. Who will?
Charlie Wiecha: I will.
Mark Birbeck: I see using index came
up in the thread already.
Charlie Wiecha: Yes.
Mark Birbeck: There should be a neater
solution.
Action 2007-05-2.3: Charlie Wiecha to reply to http://lists.w3.org/Archives/Public/www-forms/2007Apr/0027.html with the index solution for now, and say that we have added the general case to our futures list.
Steven Pemberton: [reads]
John Boyer: We need someone versed in
submission issues to take this offline.
Mark Birbeck: I know we've implemented
this; I'll ask Paul, who's done this, to read it.
Charlie Wiecha: It may be a SOAP issue
rather than an XForms issue.
Mark Birbeck: I guess it's that we've
got two ways to
Action 2007-05-2.4: Mark Birbeck to check his implementation decisions on http://lists.w3.org/Archives/Public/www-forms/2007Mar/0060.html
Leigh Klotz: This appears to have
the wrong link in the agenda.
John Boyer: I'll find the right one
later.
John Boyer: I wasn't aware that a
trigger that was readonly would somehow behave as if it were
disabled. The description says "grayed out."
Leigh Klotz: We've had use cases for
displaying greyed-out unselectable select items with hints that
display and the hint says why.
Erik Bruchez: We have two use cases; a
trigger hidden or shown, and another shown but greyed out. The
problem is that if both match relevance you need to resort to
style. That's less convenient than having two different MIPs.
That's the initial rationale for saying a readonly trigger is there
but greyed out; consider a readonly input field; you are fairly
likely to display the contents of the input field, but you are
likely to grey out the field and make it not focusable, whereas if
it is non-relevant it would be non-visible or not show the data to
which it is bound.
John Boyer: I can relate more to the
way you might choose to display by default. But for textarea, you
might make it readonly to show what someone else has typed in in a
previous stage of a workflow. For example I might get readonly
fields where someone else has filed the vacation request and I just
read and approve.
Mark Birbeck: Greyed out usually means
not relevant in operating system dialog boxes; it's an indicator of
what you might get if you tick the box above. They're read-only yet
in our model you're going from non-relevant to relevant. You have
to be careful.
Erik Bruchez: How do people usually
implement relevance? I know you can style them any way you want in
theory, but what do people do? By default we don't display it at
all. This applies to groups as well, to emulate XForms switch, the
ref=".[]" trick for example.
Mark Birbeck: So you asked what do
people normally use?
Erik Bruchez: So a trigger that is
non-relevant is not displayed at all.
John Boyer: In our case, if you turn
the visible property on, they show.
Erik Bruchez: That's not in
XForms.
John Boyer: Yes, that's in our host
language.
Mark Birbeck: By default...they're
hidden. That's not the only way. We have forms where we use a
different technique.
Leigh Klotz: What's issue here? It's
not about the presentation because CSS or as John points out the
host language is in charge.
Mark Birbeck: So people think one
thing about input, and at least two things about textarea. But what
does readonly trigger mean?
John Boyer: If you set a readonly MIP
on a node the trigger is bound to, does the trigger not work and
does it look disabled?
Mark Birbeck: It's hard to suppress
that the control can suppress events. Where do you stop? Can the
output suppress keypresses? When a span has focus, the keypresses
get reflected through the DOM. So why not output? As for the
appearance, that's different; I wouldn't have a big objection if we
added to our suggestions for consistency, as there's no
requirement.
John Boyer: If it appears to be
disabled it would be problematic if it worked.
Mark Birbeck: To quote David Landwehr,
it doesn't create non-interoperable forms. A voice system would do
it differently anyway.
Erik Bruchez: It would create
non-interoperable forms.
Mark Birbeck: We don't have the notion
of disabled in XForms. We don't say that readonly input should not
propagate the onclick event.
John Boyer: For a readonly node, the
only thing we concretely say is that the input won't modify the
node. We kind of assume that that roughly means that the user won't
be able to enter any character data into that input.
Mark Birbeck: But you could easily
come up with a use case with a Google map and a pin in the middle
and allow the user to drag and zoom; the control isn't disabled,
but you can't modify the data.
John Boyer: Or page up and down in a
textarea. It is readonly in the visual UI sense.
Mark Birbeck: I have a problem with
trying to say too much. You're right; we say can't modify the model
but beyond that we can't predict all the UI use cases.
Steven Pemberton: Do we feel that
we resolve the issue? Erik?
Erik Bruchez: I was answering John's
email. I have an opinion contrary to John's and Mark's. I'm
sensitive to the separation argument, so I'm fairly inclined to
agree with that. I remain fairly ...
John Boyer: What if it has an action
that does just a send or a setfocus?
Erik Bruchez: It doesn't have a value.
If an implementation allows scrolling in a readonly text area,
fine. The input stores data and shows it. But for trigger, the only
reason you have it is to click and the only reason to bind data is
to leverage MIPs.
John Boyer: I'm halfway between Erik
and Mark; I thought you couldn't activate the trigger, but not on
the display.
Mark Birbeck: I wouldn't disagree if
we were talking about relevance. But readonly, I think its a
stretch. It does seem odd that readonly would have an effect; do we
then move onto invalid? We fixed it lately so that non-relevant
controls aren't there, so they are disabled.
Erik Bruchez: Yes, non-relevant
controls are effectively disabled. So it's a little funny that they
can be styled.
Mark Birbeck: It's not a real control;
it's a picture, a snapshot.
John Boyer: It's not that it's not
there; it disconnects its event handlers.
Mark Birbeck: That's much more what
disabled means to me.