Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Roger Pérez, SATEC
Doug Scheppers, W3C
Steven Pemberton, CWI/W3C
Uli Lissé, Dreamlabs
Keith Wells, IBM
Steven Pemberton: It wasn't quite
as well attended as last year, but a good conference. I gave a
half-day tutorial on XForms which was attended by about twenty
people, which is sizable. I learned of two new implementations, one
at the exhibits. The other one is Mark Birbeck plus IBM's
Ubiquity.
John Boyer: We thought we'd promote
ubiquity of XForms
Steven Pemberton: There was a huge
amount of RDFa.
John Boyer: I have been working with Mark Birbeck to launch this new project for XForms. http://code.google.com/p/ubiquity-xforms/ It's a pure AJAX library implementation of XForms with the ability to be glued to a number of UI libraries such as YUI, Dojo, Scriptaculous, etc. The key is to to promote ubiquity of XForms on the web under the Apache license and to make it available under all the platforms. I think there's a lot of opportunity to contribute and to wrap projects around the core implementation. It's a JavaScript license, completely in the browser.
John Boyer: It seems like it's time
to have a registration page. http://www.w3.org/2002/09/wbs/32219/formsftf200806/
Keith Wells: I won't be able to
attend.
Charlie Wiecha: We have our kickoff call Friday at 10AM, either weekly or biweekly. If it's weekly we'll have to change time due to HCG. I've invited some others to join, but the Voice issue is up. Please join up if you can. We have about half a dozen at this point. It would be good to get more. It would be good to tie some discussions to the code project for experimentation, perhaps in another project; it would then not be just a paper exercise.
John Boyer: Nick I heard you are
eager to get started on the spec-ready text, even though you don't
have ten items. I can help create the bundle.
Nick van: I'm glad to help.
John Boyer: We have lots of technical
knowledge; the exercise is getting it communicated. You can put it
in the wiki page first if you want, but the ideal would be to work
together.
Leigh Klotz: Felix Sasaki has said
their group is not publishing now, but they would like to work with
us to publish a guide on how to use ITS with XForms. I suggested we
put it outside of TR space, as we did with Steven's guide to XForms
for XHTML authors.
John Boyer: In the wiki?
Leigh Klotz: No, as a document, but
just not in TR space. It's like a Note, but not headed towards a
spec, just informative.
John Boyer: There are two issues:
specifying presentation without CSS in the spec, and updating the
sample section on CSS.
Leigh Klotz: The first is hard.
Leigh Klotz: John, I should send you a
message and see if my concerns make sense.
Strawman "architecture alignment" response: http://lists.w3.org/Archives/Public/public-forms/2008Apr/0068.html
Latest in thread: http://lists.w3.org/Archives/Public/public-forms/2008Apr/0084.html
Need responses to
John Boyer: Nick and Keith, can you break down some of the messaging on the principles and get them out as discussion points? They also had some feedback. So break it down.
Got resolution last week on basic principle of adding form tag
John Boyer: For point B, I'm a
little fuzzy on accept and accept-charset. Is there a submission
expert?
Leigh Klotz: If it's not UTF-8 I don't
understand it.
John Boyer: Me too.
Nick van: http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.3
John Boyer: "This attribute specifies
a comma-separated list of content types that a server processing
this form will handle correctly. "
Leigh Klotz: This is the mediatype
attribute on xf:upload: "User agents may use this information to
filter out non-conforming files when prompting a user to select
files to be sent to the server (cf. the INPUT element when
type=file)."
John Boyer: OK, so we could use it in
upload.
Leigh Klotz: Default if not otherwise
specified.
John Boyer: That seems reasonable. http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.3
John Boyer: For accept-charset we may need to look at it more closely.
Action 2008-05-14.1: Nick van den Bleeken to read http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.3 and make proposal for accept providing default to xf:upload/@mediatype and make proposal for accept-charset for http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.3
The submit element would use default submission of form tag,
Looking for resolution of above http://lists.w3.org/Archives/Public/public-forms/2008Apr/0063.html
Nick van: I made a wiki page about
this.
http://www.w3.org/MarkUp/Forms/wiki/Allow_submission_elements_without_model_element
The idea is allowing the submit or a send to refer to a submission
but also override the attribute you can specify on the submit or
the send. For example, a different resource to submit to two
different search engines.
John Boyer: So would they override the
default submission of the default model or would they create their
own?
Nick van: Create their own.
John Boyer: And they would default
from the form tag?
Nick van: I'm not sure we need to
decide. If you don't specify a submission then they get the
attributes from the form tag; that sounds reasonable.
John Boyer: You can't submit the form
unless you have a submit control inside the form tag. So the thing
that implies an XForms submission is the existence of a submit
tag.
John Boyer: We need someone to write a
proposal for the group for this kind of things.
Leigh Klotz: You don't need a submit
in HTML4 for submission.
Nick van: Enter will do it.
John Boyer: Does that work
everywhere?
Nick van: Yes. They listen for enter
key on input. Leigh : Yes.
John Boyer: That suggests you need to
imply a submission. What if you put an input
type="submission"?
Nick van: It will do a
submission.
John Boyer: Can you override it?
Nick van: You can cancel the default
in onsubmit.
Leigh Klotz: I can't remember the
outcome of multiple submits and enter.
Nick van: None are added, but mostly
they use an onsubmit handler.
John Boyer: If you have an onsubmit
handler is it cancelled?
Nick van: It depends on the return
value.
John Boyer: We'll have to respond to
this in the streamlined stuff as well, being able to cancel what we
call the xforms-submit event.
Nick van: Isn't that something needs
to be described in the HTML attributes model? We won't add it to
our language.
John Boyer: It would be a note to the
HTML onsubmit implementer. If it returned zero, say, we'd set the
cancel flag on the xforms-submit event.
Nick van: Adding onsubmit doesn't make
much sense in xforms.
John Boyer: Yes, it's like name. A
form author may add them but we don't directly respond. It's like
globally-named attributes that a particular processor may
support.
Nick van: We need a chapter or module
explaining it. Our buttons don't add data to the instance, for
example.
John Boyer: We have two techniques in
the spec to merge that in. We can define the section as
informative; it can be advisement on how to integrate. Or we can
use a note; a lot of people tend to regard normative notes as
normative.
Nick van: We'll have a lot of
them.
John Boyer: It took only a couple of
sentences to say that the XForms processor doesn't interpret some
attributes from the form tag. It can be fairly short. We just need
proof (by exhaustion) that we have considered the existing
language.
John Boyer: So, as part of the streamlined syntax, we need to respond to a submit control and also input type="submit". That has a slightly further problem with a name conflict. I've held it as self-evident that this means that we want our type MIP to be expressible somehow on a UI control. The attribute name can't be type.
John Boyer: ...
Nick van: It's
submit-without-models.
John Boyer: Can you take that
on?
Nick van: Yes.
John Boyer: Can you move that action
over to you?
Need to discuss #3 in http://lists.w3.org/Archives/Public/public-forms/2008May/0013.html
John Boyer: If we had scopes, it
would be fairly easy using XForms actions to ferry data back and
forth. I know there are alternate opinions.
Charlie Wiecha: Another approach is to
extend setvalue and use s1 and s2 as sibling implied models. We
need an extension either way for cross-model assignment (not
constraints or calculate).
John Boyer: Doesn't that wind up with
spaghetti code?
Charlie Wiecha: It would allow for
assignments across models.
John Boyer: Nested models give
containment.
Nick van: Don't you need to
communicate from the outer model to the inner model. I think we
might need to postpone this to 2.0, but the behavior now with
nested models would have the outer model nested?
John Boyer: I meant the email you
posted. #3 in 0013. Free communication between two models with
nested containment in either direction. That's the only difference
in actions talking to anything. Going back to what you said,
Charlie, you have to modify actions anyway. You have to have two
different models for setvalue for ref and value.
Charlie Wiecha: Unless you have a
grey-box approach where you know the ids.
John Boyer: What if you contain
...
Leigh Klotz: We could have an
interface section of targets for actions (setvalue is close to
action with a payload). You don't have to worry about which model
for the attributes-on-attributes problem for setvalue.
John Boyer: I was wrong on that.
Leigh Klotz: But it's one of the
sinkholes we come close to.
Charlie Wiecha: We want to do
something without re-inventing CORBA with angle brackets.
Leigh Klotz: Sounds like we want to
make a mess but not too big a mess.
John Boyer: If we kept it as a
separate DOM and defined an event flow (like repeats) we wouldn't
have an ID conflct but we'd have a way of defining an interface
that the included model exposes.
Charlie Wiecha: Then we don't care
about nested vs sibling.
John Boyer: The nested model
flattening made me uncomfortable because of id conflict. I like
Leigh's proposal but I think we need to work it out sooner rather
than later. Should I do the work or are people uncomfortable?
Leigh Klotz: What did you mean by
DOM flow? DOM of the model or DOM of the inter-model instance
data?
John Boyer: The latter. Rather than
defining the fact that those things are pulled in, they don't have
to be pulled into the same DOM.
Nick van: I see a lot of extra work,
but I could be wrong .
Leigh Klotz: That's the former.
Charlie Wiecha: We need both.
Uli Lissé: I hate inner
classes in Java and I don't like nested models. I think sibling
classes is better. I think cross models via the id interface are
better. I think we excluded cross-model communication, but with
scripting you can have it anyway. I'd like to see more formal
stuff. I don't think it's a good idea to have models sucked in via
src created as the own DOM; the instance would them have its own
DOM and it gets too complicated.
Charlie Wiecha: That's what I was
saying.
Uli Lissé: I'd like to see
accessing data from one model in another.
John Boyer: [irc] Instead of nested
models, solve cross-model communication, possibly by defining the
interface in the model
John Boyer: So the person who writes
the model definition may have a greater skill set than the person
consuming the skill set. It's not a big stretch to say that the
person who wrote serviceDefintion1.xfmodel can write
<interface>.
Steven Pemberton: [irc] has to go
Charlie Wiecha: The current src
attribute on instance, what do we do with id attributes?
John Boyer: It's created as a separate
DOM.
Charlie Wiecha: There's one for the
running instance, but do we keep that DOM?
John Boyer: The xf:instance element
has src but whatever it points at is not xf:instance.
Charlie Wiecha: So we don't keep the
"source" but just the running instance copy.
John Boyer: It's similar.
Charlie Wiecha: Here we have the model
declaration which has to be separated into the shadow tree.
John Boyer: Nick, you said you see
extra work. It might make sense to flesh it out for the willing
volunteer to see if it's extra work. To me it sounds like a not
more work. The harder part is defining what model/@src means.
Nick van: I think there are a lot of
roads we can take and coming to a consensus will be a lot of
discussion.
John Boyer: So for 1.2 we either
abandon model/@src or we have to solve the cross-model interface
problem.
Nick van: The same holds for canonical
forms. So it's not a streamlined thing only.
John Boyer: We are adding a lot of
syntax to XForms-canonical in order to support streamlining; the
question is whether this is something we need to add?
Charlie Wiecha: I see it as a great
issue but not a streamlining issue.
John Boyer: OK, then we defer this and
model/@src to 2.0. I like it but I can live without it.
Nick van: I like it but we are already
late.
John Boyer: Sounds like a resolution:
model/@src is XForms 2.0.
Nick van: [irc] +1
Uli Lissé: I don't object but
I'd love to see it in 1.2.
John Boyer: Can you live with
it?
Uli Lissé: I'd like to drop
nested models but not @src.
John Boyer: If we solve the @src
problem in 1.2 we'd have to solve the interface problem.
Uli Lissé: I don't object to
the resolution.
John Boyer: Any objections?
Resolution 2008-05-14.1: Defer model/@src to XForms 2.0 and we solve the cross-model interface problem there too.
John Boyer: The related issue is,
what happens if someone puts a model inside a form tag? Does it
take over the model?
Nick van: Take over, merge with
implicit model, or two separate models.
John Boyer: That's the homework
assignment for the week. Nick, can you start that on the list?