John Boyer, IBM (chair)
Mark Birbeck, x-port.net
Mark Seaborne, PicoForms
Rafael Benito, SATEC
Steven Pemberton, CWI/W3C
Uli Lissé, DreamLabs
Keith Wells, IBM
Charlie Wiecha, IBM
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
http://lists.w3.org/Archives/Public/public-forms/2007Aug/0086.html
John Boyer: There are two issues.
First, is the keynote speaker. It's looking promising. Do we have
any progress on deciding the presentations.
Leigh Klotz: Did you get any answer on
extending the presentations?
John Boyer: No, but I'll ask.
Leigh Klotz: We'd like you to ask for
more time again, even less than enough for a full presentation, so
that we can either have a full paper or combine two or three into a
panel (either from the same company, or on the same subject0.
John Boyer: I'll ask.
Action 2007-09-5.1: John Boyer to query about getting extra time, even 15 minutes, for the XForms conference.
Attendance Questionnaire: http://www.w3.org/2002/09/wbs/34637/ftfsept2007/
Nick van: [irc] for the SATEC f2f are
we going to stay in the center or near to SATEC?
Steven Pemberton: That would be best
but I am bound by the per diem. But generally, people are staying
in the center?
Rafael Benito: A taxi will be 20-30
Euros but be careful.
John Boyer: So can we meet downtown
and pool a taxi?
Steven Pemberton: Do you recommend a
place to meet?
Rafael Benito: Which hotel?
Steven Pemberton: Is there a central
spot?
Rafael Benito: Puerta del Sol.
Nick van: [irc] charley you were
staying in this hotel
http://www.nh-hotels.com/nh/en/hotels/spain/madrid/nh-abascal.html
Charlie Wiecha: [irc] I got 109 euros
there. but that was a negotiated rate
Rafael Benito: But I can recommend a
less populated place.
John Boyer: I'm at Sofitel.
Steven Pemberton: There's a metro at
the Puerta del Sol, so we could gather there and take a taxi.
Charlie Wiecha: Meet for
breakfast.
Steven Pemberton: Do we want to agree
on what time we're going to meet there?
Rafael Benito: Our working hours are
9:00-6:30, but meal times are late. So maybe 9:30-15:30 for the
meeting, with a break for lunch at 1:30.
Steven Pemberton: OK.
John Boyer: Sounds good. Where do we
meet?
Steven Pemberton:
http://maps.google.nl/maps?f=q&hl=en&q=puerta+da+sol,+madrid,+spain
Rafael Benito: Puerta del Sol, under
the clock, leaving at 8:45.
Steven Pemberton: So meet at 8:00 for
coffee.
Resolution 2007-09-5.1: Meet at Puerta del Sol, under the clock, at 8:00 for coffee, leaving at 8:45. Meeting is at SATEC at 9:30-17:30, with lunch at 1:30.
John Boyer: Will we be able to get
lunch within an hour.
Rafael Benito: Yes.
John Boyer: I wanted to clean up a bunch of things that need to be dealt with in part to deal with issues. Some could have been dealt with a with a band aid ("definition of form control") or I could have made the fixes by tightening up definitions, but the intent in creating the editor's draft was not to decide without debate, but to put together spec-ready text to show what we can live with and see what we can change. The problem is that addressing some of the last call contents, here were points of vagueness that made it impossible. I think we're in a better state now even if we make a radically different decision on these points.
John Boyer: The "new line"
distinction between input and text area. It was one of the minor
issues. I sent an email to clarify why I thought we had to say
something about multiline text. I drew the analogy to select vs.
select1. XForms has an intent-based user interface. It seems odd
that we would have two different controls that have no differences
in intent. Whereas textarea says it is intended for multiline text,
input says nothing either way. There is a history that input comes
from HTML forms and doesn't accept the enter key. The enter doesn't
go into input; it is rather gone to submit the form.
Steven Pemberton: We don't say that
anywhere.
John Boyer: We don't have a default
submission for DOMActivate bubbling up. If you had an input (as
opposed to a textarea) then hitting input should cause the
implementation set its value and then dispatch DOMActivate to its
input.
Steven Pemberton: What I remember is
that we had a number of points and some of them are about device
independence, and some of what you're describing is platform
standards, and aren't definitions of HTML. A device that has no
return, or if return is used for some other purpose, we would be
overspecifying. We try not to bind the concept; we don't have a
return, but we do have activation. We don't say anything about
binding to particular keys.
John Boyer: I don't remember I said
particular keys.
Steven Pemberton: Return is a key
binding. I understand what you're saying but I don't understand how
to say it.
John Boyer: I just said "should
disallow user entry of multiline text."
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#ui-input
I don't say anything about return.
Steven Pemberton: What's the value
add?
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#ui-input
John Boyer: Trying to create a hard
return...DOMActivation...
Steven Pemberton: I've seen programs
that use shift-return for multi-line and return for submit, but
those are decisions made by the user agent.
Mark Birbeck: Yes. Also when you copy
some text with multi-lines and paste it into a single-line box, you
can still paste the data, but to say that the input can't cope
means you can't paste it on.
Mark Seaborne: [irc] for our mobile
client there is no concept of "return".
Mark Birbeck: You'd have to read it
back in. But it's hard to say it in a platform-independent
way.
John Boyer: Why do we have textarea at
all?
Mark Birbeck: Why do we have select1
vs. select?
John Boyer: When you have a
select1...
Steven Pemberton: It's a difference in
datatype; one is a list type and the other isn't.
Mark Birbeck: You could have an input
control as the only control.
Steven Pemberton: There is a point of
view that says we only need one, as you've shown with XBL.
Mark Birbeck: You could have an input
control with child of itemset.
Steven Pemberton: Yes.
Mark Birbeck: It's not the that
distinction between these controls is as clear as you would think.
A boolean with input could be checkboxes, but to me that's a
select.
Steven Pemberton: Yes.
Mark Birbeck: Is it possible to do
this, John, as we did with help and hint? So we don't say
multiline, but we could suggest behavior that the enter key fire
the DOMActivate?
John Boyer: And commit the
value.
Leigh Klotz: Commit the value first,
as we discovered.
John Boyer: Yes. And yes, input allows
free-form data, but as you say for boolean, it's not really
free-form.
Steven Pemberton: Does input say
free-form?
John Boyer: Yes.
Steven Pemberton: I wouldn't agree
with that. You can get a date picker. That sounds too
specific.
Mark Birbeck: If you bind select1 to a
date you should get a date picker as well.
John Boyer: That might be
interesting.
Charlie Wiecha: You get a calendar
with the two dates highlighted and you get to pick one.
John Boyer: I don't know that anyone
is ever going to implement that.
Steven Pemberton: On the other hand we
don't believe it should be disallowed.
John Boyer: Textarea says intended for
multiline content; input says freeform.
Steven Pemberton: I think anything
else is too hard to make it freeform.
John Boyer: All I added was "should
disallow entry of multiline text"
Steven Pemberton: I don't agree with
that. If you do everything with input and use XBL, it might be
possible that an input does accept multiline text.
Mark Birbeck: You're linking multiline
text with the enter key. Why would we prevent it? All we're really
after is the search scenario where you press enter.
Steven Pemberton: In that case, it's
the user agent doing the right thing. Anybody who doesn't do the
right thing, people would get cross with them.
Mark Seaborne: [irc] our
implementation uses input for multiline text
Mark Birbeck: To have a sentence about
it would be quite useful, just like making select many into
checkboxes rather than radio buttons; it's a suggestion that works
out.
John Boyer: So if we were to add a
note to say something, would that be satisfactory.
Steven Pemberton: Yes, an informative
note is just fine.
Leigh Klotz: Or an example instead
showing DOMActivate?
John Boyer: I can throw that in and
get rid of the offending implementation requirement. When does the
DOMActivate happen?
Leigh Klotz: We have a graphical
example here already of Street.
Mark Birbeck: Something has to commit
the data first; that's not part of the definition of input.
John Boyer: When they signify that
they want it to be committed?
Leigh Klotz: Is the problem that we
can't tie DOMActivate to setting the value?
Mark Birbeck: What about trigger and
select?
Leigh Klotz: Trigger doesn't have a
value and select already says it doesn't commit unless it is
incremental. The question is how to we say that the user agent
should offer a way to perform the sequence of commit-value and
DOMActivate.
Mark Birbeck: We can say there is a
default handler on DOMActivate that commits the value.
Leigh Klotz: Then you get the value
committed after the submit.
John Boyer: It only happens after the
capture phase.
Mark Birbeck: I think you can say when
it happens.
John Boyer: I'd like to see that.
Action 2007-09-5.2: Mark Birbeck to check with
XML Events Rec on documentation for when default handlers can be
run with regard to input/send[@ev:event=DOMActivate]
committing values.
John Boyer: I'll take the action to add the example.
Action 2007-09-5.3: John Boyer to remove line of text about multi-line text and write example for input section showing DOMActivate causing send for group review.
Nick van: If the input is bound to
a boolean how do you activate it?
Leigh Klotz: Changing its value.
John Boyer: Maybe in a graphical
browser, enter?
Steven Pemberton: Space certainly does
it.
John Boyer: We're struggling because
we have to put an DOMActivate on every control.
Steven Pemberton: I'm not sure what
the value add is here. Nick?
Nick van: I already said it, about the
checkbox.
Leigh Klotz: I think it's reasonable
for an implementation to active a checkbox when you change
it.
Nick van: [irc] but that breaks Johns
example for default submissions
John Boyer: Sometimes by "form
control" we meant to exclude group, and sometimes we meant to
include group, switch, and possibly repeat as well. So if you look
at the table at
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#rpm-events
"core form controls" means the non-container controls. But
xforms-next and xforms-previous didn't really make sense, so we can
go change it. For any place that says core form controls we can say
group as well, but then what about switch?
Nick van: [irc] not for all I
think
John Boyer: For example, DOMFocusIn,
DOFocusOut, I said core+group+switch+repeat because we have
setfocus and a last-call comment that says we have to say what it
means to set focus to a control that is a repeat. That ended up
suggesting that the repeat was a control. xforms-disabled and
xforms-enabled list core+group+switch because they have special
things with relevance; they impose relevance on their contained
controls. I did not list (as a first cut) group and switch as
targets for xforms-read-only and xforms-read-write and assumed the
spec was wrong. If we do dispatch those, we should clarify in group
and switch sections that they don't do anything with them (i.e.
they won't force readonly-ness on their contained controls).
John Boyer: Mark Birbeck suggested
we go back to vagueness but I think it was inconsistency. We can go
with this text as it's better than what was there before. I hear
that there was concern with readonly and we can change it. We can
check relevant and see if it has a special meaning with action.
readonly can be respected by form controls only, or it can be
enforced by the model (view + control). So either way. But we
should be ready to talk through that at the F2F.
Nick van: [irc] John did you read my
e-mail about that?
Mark Birbeck: On vagueness, I think we
should have this discussion but we don't have time yet. I'd say
that a recursive MVC would be best. I'd like to leave it vague
because we don't want to make changes that inhibit other routes
that we want to go later on. I'd like to link this to backplane and
look at the model as a separate thing and see what we want from it.
The problem with the discussion that just happened was Mark
Seaborne's point, that some of the things might prevent us from
going down another route later, as they imply a philosophical
approach that we haven't agreed on.
John Boyer: We have the practical
problem that insert and delete insert into readonly content and we
have (I'm guessing) some implementations that prohibit it.
Mark Birbeck: We have to ask if we
want to get out of XForms 1.1 or not. We have plenty in here that
needs to get out now (headers, dynamic submissions). I don't think
a problem that we've had since XForms 1.0 needs to be fixed
now.
John Boyer: Certainly we need to get
more features in. OK, we've reached the top of the hour and will be
meeting next week. That's where the changes are coming from. We've
got to resolve last-call issues. We're up against the wall; we have
to finish in September to CR, but it's looking harried.
Steven Pemberton: We have to work
really hard next week. I think we should be able to do it.
John Boyer: We have some hard ones
coming up. I'll try to get each last-call issue into a time
frame.
Steven Pemberton: One more thing on
the agenda: SMIL-3 is in last call and we've been asked to do a
review; they use XForms concepts for state.
John Boyer: Anybody to review?
Steven Pemberton: I think Mark.
Mark Birbeck: I will.
Steven Pemberton: I will. And people
should have skimmed the section on state in SMIL 3.