Charlie Wiecha, IBM
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net
Steven Pemberton, CWI/W3C
Uli Lissé, Dreamlabs
Keith Wells, IBM
Roger Pérez, SATEC
Rafael Benito, SATEC
http://lists.w3.org/Archives/Public/public-forms/2008Jan/0014.html
Leigh Klotz: The #ui-processing
section talks about inline layout and block layout and CSS, but
appendix G.3 is now at odds with that and ought to be updated.
*:disabled with visibility hidden isn't the way we do it. It shows
both one we think you should do and what you might do.
John Boyer: So we should make it into
two examples?
Leigh Klotz: Or get rid of it.
John Boyer: So we need someone to own
it.
Leigh Klotz: I can collect the
normative issues but someone else had to do the others. There are
many holes in the way CSS and XForms are deployed together and so
there are many fills for those holes.
John Boyer: So we need a re-write of
this example but it's using things that aren't working
everywhere.
Leigh Klotz: So we should collect
together then ones that work.
John Boyer: Does CSS3 allow you to
define your own pseudo-elements?
Steven Pemberton: It doesn't, but it
ought to. We've said so in the past.
John Boyer: The response was?
Steven Pemberton: Put it in your own
specification. It's not officially allowed but they said to do
it.
John Boyer: So someone else creating a
CSS3 might not do that.
Leigh Klotz: But someone implementing
CSS3 and XForms would, as PicoForms had done.
John Boyer: Leigh you indicated you
would collect together the things that work?
Leigh Klotz: The ones implied by the
normative text.
Steven Pemberton: Then we can put in
the list of special class names for when CSS2 or CSS3 isn't
working. In Spain? Mark?
Mark Birbeck: I think that was in your
house. Or Cannes. One of the action items was that I was to create
some pages to comment on them. I have those pages but we've never
discussed them. http://www.formsplayer.com/node/384
Leigh Klotz: I'm happy to do this but
I don't want do neverending examples, but maybe just the form
control layout as a full page.
Steven Pemberton: Here's a suggestion.
Mark Seaborne is back soon. He's good at making XForms look really
nice.
Leigh Klotz: I'll take a stab at form
layout one and Mark or someone else can fix it later.
Action 2008-01-16.1: Leigh Klotz to split appendix G.3 examples into two parts: a CSS file of stuff implied by the rest of the spec, using both CSS3 and the substitute class names from http://www.formsplayer.com/node/384; an example of form layout for elaboration later by others.
Steven Pemberton: Registration is now working; please go register.
John Boyer: I reset the date to February 2008 for the first public draft because I expect it to be an outcome of the F2F. We need to have some sections already picked and elaborate them during the F2F. That's my sales pitch. I did a lot of work in the Wiki recently: http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features I tried to divide it up into two versions and assign priorities for 1.2 and 2.0.
John Boyer: The first issue is
simplification. Are we comfortable with not having a model
element?
Mark Birbeck: The default is that
they're free-floating and a model element then sets the evaluation
context for bind and submission.
John Boyer: What if you put an
instance inside a repeat, or a group?
Mark Birbeck: It has an id. Those are
funny formulations we've implemented. Instances (except the first
submission and instance rule) are identified by id. So there's not
any reason for submission or instance to be tied to a model.
John Boyer: So when the referrer and
the referred are both inside a repeat we have the rule.
Mark Birbeck: Ah so do you repeat the
instance? We may have to restrict some things. Just setting an
evaluation context, action handlers, etc. all inside a model and
you don't need to use an instance() function. There's the ability
to re-use stuff so you could hand a model. It would have all
handlers, etc. and would log you into GData.
Charlie Wiecha: The converse is moving
scratchpad instance closer to where it's used.
John Boyer: So does it take its
context from the data or the reference?
Charlie Wiecha: No proposal yet.
Mark Birbeck: We allowed model not to
be restricted to the head; we have blocks of code instantiated
dynamically but we need a model. Say you are doing a select using a
"Google Suggests" AJAX approach. Those values have no relevance to
the rest of the form; it's a scratch instance, as Charlie said; it
has a little submission as well. That can fit very close to the
control that it's.
John Boyer: There's refactoring into
modules, etc. as XForms 2.0.
Mark Birbeck: The form element, for
example.
Charlie Wiecha: The example Mark gave
doesn't quite get into that turf. Just a free-floating instance is
fine without modularization. We need to divide 1.2/2.0 more
carefully but I think it's ok.
John Boyer: So free-floating instance
by id only?
Mark Birbeck: Hmmm...the first
instance rule? Not mixing 1.2/2.0 features...how do you go from an
HTML form to an XForm...making model optional lets us interpret an
HTML form as if it were an XForm, so we don't need complete
flexibility. If letting the instance free-float is too far,
ok.
Charlie Wiecha: If it doesn't fit the
on-ramp.
John Boyer: If we had a free-floating
instance then the one without the ID would be the default. So
Steven said it would be the first instance in the form tag; if you
specify no instances then you get the default.
Charlie Wiecha: Then you pull the
controls inside the model rather than having a model-free.
John Boyer: It's like an implied
group.
Charlie Wiecha: That's very
nice.
Mark Birbeck: Model is still a key
term in procedural aspects (rebuild, etc). So it's a processing
concept rather than a markup concept. Then form controls can be
inside model.
Charlie Wiecha: The events are
dispatched to form instead of some anonymous node inside the
form.
Mark Birbeck: So xf:action under form
will still give you rebuild. So form represents all those things;
you'll get the submission events as well.
John Boyer: model-construct-done and
xforms-ready. We might come up with a simpler way to express
defaults and initialization.
Charlie Wiecha: It might be
nice.
Mark Birbeck: And if an author
suddenly needs three submissions in a form, fine.
John Boyer: What if you want to use
an instance for a particular reason, but you don't actually want
that instance to overload the default instance implied by the UI?
For a web service?
Mark Birbeck: You then create a model,
instance, submissions, for the web service.
John Boyer: Then you need cross-model
communication?
Leigh Klotz: Doesn't Charlie do that
with XAC?
Charlie Wiecha: 2.0. Use a
listener.
Mark Birbeck: I thought we could do
cross-model setvalue?
John Boyer: No, only one model.
Mark Birbeck: We have a
getGlobalInstance function. You have to be careful in a bind as it
doesn't create a dependency. It moves data a to location b.
John Boyer: Or have it called only in
an action.
Leigh Klotz: How about a submission
target that's an instance in another model.
Mark Birbeck: But you still need a
function. Ah you mean the instance attribute?
John Boyer: Right now it says it's
only in the same model.
Charlie Wiecha: How about nesting
them?
John Boyer: I added nested models to
the Wiki. Instances could be made visible to containing models. So
the model inside a form could have internal access to its first
instance by default but operate over the model of instances in its
ancestor container models.
http://www.w3.org/MarkUp/Forms/wiki/Nested_models_for_convenient_grouping_and_composition
Charlie Wiecha: That seems more
bounded.
Mark Birbeck: So all nested model
elements add to the outermost model. The only bit you gain by
nesting them is the evaluation context.
John Boyer: If you have a model that
is operating in isolation and compose something with it, and then
that changes the default instance, it breaks as soon as you compose
it. If calculates in it rely on the default instance in that model
and then you put it inside some other model, if we claim the
nesting amalgamates them together, then the submodel gains the
first containing model's default instance.
Charlie Wiecha: No, that's not what
we're saying.
Mark Birbeck: If we have a reference
inside a model with a /, that refers to the first instance in that
model. If I put that inside another model, it's still the same. But
for rebuild and recalculate, when the submission has finished,
you'll need to a rebuild on all the models all the way up the chain
because you have one model. The nesting is for scoping only, like a
block. We'd have cross-model problems if we don't do rebuild on the
contained models.
John Boyer: There's some optimization
issues there for very large ones.
Mark Birbeck: If a nested model is
allowed to refer to any models in the hierarchy above it, then it's
the same as siblings.
John Boyer: So access is
automatic.
Mark Birbeck: But you have to rebuild
everything.
John Boyer: Over time it becomes an
optimization issue.
Mark Birbeck: So we should look
further into optimization as we said in 1.2.
John Boyer: If we limit cross-model
access to a containment scenario, it might be easier to deal with
other time because you don't have arbitrary connections.
Charlie Wiecha: How about the parent
to the submodel as well? You need that.
John Boyer: Yes, more in the way Mark
has described, where the containment goes both ways. The default
reference is in teh descendant model.
Leigh Klotz: So the namespace is
flat.
John Boyer: In terms of ids.
Mark Birbeck: We are restricted by XML
itself. Maybe use name?
Leigh Klotz: Or use reference instead
of inclusion and the ids would be other documents, as can be done
with XML Events.
John Boyer: We use sid, scope ID,
unique in the containing element.
Mark Birbeck: In experiments I've done
with creating models to be re-used the issue is to try not to refer
to things inside the model, which sounds kind of obvious. Using
events as the main mechanism is more useful.
John Boyer: Why do you need to be
able to go both ways for web services?
Charlie Wiecha: We need setvalues to
go...
John Boyer: So that's done in the
child model; it gets data values from the ancestor, pulls them in,
and then pushes the values out to its ancestors.
Charlie Wiecha: I thought the ancestor
would set up the payload submission.
John Boyer: So it would attempt to
launch a submission but push its data into the web service.
Leigh Klotz: How about a ref or
instance on xf:send, so you can define a point where you pass the
parameters down, and then don't do any bind access at any other
time, preventing problems with rebuilds.
Charlie Wiecha: We started off with
default instance question.
John Boyer: Can we focus on a straw
proposal and see what we can do for 1.2?
Charlie Wiecha: I'd like to get
started on it.
Mark Birbeck: Maybe we can start with
the form element.
John Boyer: That which implies a model
plus submission.
Mark Birbeck: Plus default instance,
and then working on the problems that happen when you introduce an
explicit version of what you had implicitly.
Charlie Wiecha: We could spec the form
tag in XBL.
John Boyer: That's neat; as we're in
the Interactivity domain, move from text+schema to text+xbl. So who
gets the action?
Charlie Wiecha: I can do part of
it.
Mark Birbeck: That's a model I
described in my paper
http://www.w3.org/2004/04/webapps-cdf-ws/papers/webapps-workshop-standards-based-vm.pdf
Mark Birbeck: I think it's testable as
well as convenient. So I would like to work with Charlie on
this.
Charlie Wiecha: In Cannes we had
this admonition to use more formal methods. Is XBL formal?
Mark Birbeck: I've defined
xf:instance/@src in terms of xf:instance without a src but with an
event handler on document load, etc. It's more the kind of
composite nature. It's sort of in XBL as that's the best we have
for composite objects, but we might have something better.
Charlie Wiecha: ...
Mark Birbeck: XBL is element-driven,
but if you extended it to cover that level of granularity you might
cover that case. I've discussed a way of doing XBL with XHTML with
Steven. You can use the HTML root element and you only need a
couple of extra things.
Action 2008-01-16.2: Charlie Wiecha and Mark Birbeck to work on straw proposal for making model optional, allowing submission elements without model elements, and allowing instance elements without model element. Results to http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features
John Boyer: One of the obvious ones
is constraint.
Leigh Klotz: The analysis I did a
while back on this showed ways to combine them. There's AND and
OR.
John Boyer: It seems rather obvious
that and is the way to combine them.
Leigh Klotz: We might want to have a
constraint-valid attribute and a constraint-invalid attribute and
then to be valid you have to have either at least one
constraint-valid=true or no constraint-invalid=true.
John Boyer: I see. But what if you
have both?
Leigh Klotz: I guess the invalid
wins.
John Boyer: Then that's what we have
now.
Leigh Klotz: But it's tri-state like
CSS :enabled :disabled, which have their own boolean values
true/false, and some cases simply give you no information.
John Boyer: We need to ask if this is
valuable for 1.2 and makes authoring easier. The same is true for
other issues such as model-based switch. We can discuss more next
week.