Charlie Wiecha, IBM
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Roger Pérez, SATEC
Rafael Benito, SATEC
Steven Pemberton, CWI/W3C
Uli Lissé, DreamLabs
Keith Wells, IBM
Sebastian Schnitzenbaumer, DreamLabs
http://lists.w3.org/Archives/Public/public-forms/2008Jan/0029.html
Charlie Wiecha: We're pursuing
internal approvals and I'm sure other authors are as well. Please
send in comments if you have any.
John Boyer: The topic came up on the
last HCG call. Someone, maybe Al Gilman, was expressing concern
that it wasn't general enough. We said we meant a generalized data
model could use a general data format and expression language, and
he sounded glad to hear it.
Charlie Wiecha: We have to debate how
far to push that as it's of interest to Voice groups as well. I
personally don't have an idea of how to do it, but the group can
discuss it. I did copy it to the WAI group.
John Boyer: Yes, they'd read it.
Charlie Wiecha: I got no
responses.
Leigh Klotz: We'll be looking for
approval for authorship of the charter, and separately seeking to
join the group.
Uli Lissé: Has anyone booked
a hotel?
John Boyer: I booked the Radisson in
RTP.
Charlie Wiecha: Me too.
Keith Wells: I've heard the Radisson
is very nice; I've also the Doubletree and airport Hilton are
good.
Leigh Klotz: Is the F2F page accurate
for the Amsterdam F2F?
Steven Pemberton: Yes, 9-12 June.
Leigh Klotz: I gave them a pizza order form and they are going to localize it. It has several ways of doing it. They're going to discuss it this week.
John Boyer: Yahoo announced their
mobile XForms platform. Should we be inviting them?
Steven Pemberton: I think we should
invite them but I doubt they'll join. Perhaps if IBM invites
them?
John Boyer: I'll ask.
Incomplete example in inputmode Appendix
John Boyer: I think Charlie and
Mark Birbeck are working in this area and I want to make sure these
are included.
Charlie Wiecha: Yes, I saw that.
John Boyer: And I'd like to open up
discussion in the model with src attribute, if everyone's
comfortable. It would be nice to have some basic compositional
capability, for example storing the model separately from an XHTML
document.
Charlie Wiecha: We have to worry about
id conflict with submission, etc.
John Boyer: Ah, and instance uses a
separate DOM. But ODF and my own XFDL, once we pull in data, we
store the data within the instance document, and we have that id
problem with the resource attribute on an XForms 1.1
instance.
Charlie Wiecha: So the question is
what's the compositional behavior with what's local and what's
loaded remotely. But I guess it's good to address at the same
time.
John Boyer: It might get shot down.
But as soon as you can compose models recursively, it seems natural
to allow src.
Charlie Wiecha: So we would discuss
this in Raleigh?
John Boyer: Yes, because we need a
first public working draft by February. It can have placeholders
though. So you're OK with adding this to your topics?
Charlie Wiecha: Yes.
Nick van: [irc] I can do
that.
Uli Lissé: I don't like this at
all. I think it will complicate the processing model. Our events
come from the model item, and are related to model items, and not
from a UI control. I always think about controls being bound to the
same model item. I don't see how this could be resolved when one is
relevant and one is non-relevant. Do you see what I mean?
John Boyer: Yes. We have two issues:
we want to associate model item properties with controls rather
than nodes of data. I'm not sure this is the same thing as that.
Also we'd talked about the fact that the UI would imply a model, a
data instance, and attaching those MIP attributes to the controls
would be a shorthand for implying binds in that implicit
model.
Uli Lissé: How would you
resolve conflicts?
John Boyer: For now, for relevant, it
would be an error to use two. We do have a proposal to discuss
combining.
Leigh Klotz: I'll look for the old
report; but it's not a proposal, just a report on combining and we
decided not to allow any combinations.
John Boyer: OK. So what about when we
have two bindings? Nick?
Nick van: I think in HTML you get two
nodes. I imagine that if you want the same node you have to have
the instance.
John Boyer: Once you have the instance
declared, it's still possible that someone would want to put their
MIP expressions on UI controls, for staged adoption. Let's
brainstorm...why would they declare the instance? If they want to
bind to a single node, then asking the author to rationalize the
MIP expressions seems reasonable.
Nick van: What if you have one
readonly and the other not readonly? That seems like it could be
resolved on the UI. And for relevant, it could be the
and of the constraints. I don't know why it was
decided in the first place that you couldn't have multiple MIPs. It
seems natural to me that both constraints have to be met. I don't
know why we decided that.
Leigh Klotz: Because we wanted to open
it up later, and provide for different ways of combining. Splitting
the boolean MIPs up into pairs so we can have true, false, and no
data for each one, we can get more precision. John pointed out it
was possible to express all that with just one, but I pointed out
that this is about syntax, because you can express everything in
one bind anyway.
John Boyer: Uli's concern is that you
can have two conflicting MIPs on UI controls, but they aren't
conflicting because one attempts to apply to the UI controls.
Uli Lissé: I think it will be a
pain for implementers and maybe authors.
Steven Pemberton: Are we really,
really sure we want to do this? I'm not sure who we're trying to
please. The more I think about this, the more I think it sounds
like the style attribute. It sounds like wanting to carry on the
old ways. There are so many arguments for splitting model and
control. It seems to me that we're playing to an audience who
aren't interested anyway. We should be true to ourselves.
John Boyer: This is for support of
glass-to-data authoring style, not data-to-glass. We let their UI
gestures imply a model. For people who don't want to use a visual
design experience, they have no way to continue to think in that
way, unless we open up the syntax for that a bit.
Nick van: There's also the second
reason I proposed this: If you have a separate model and UI
designer and the model designer gives the constraints for the
back-end, and the UI designer just wants to enforce more
constraints such as readonly, then if you have these MIPs on the
controls you can do it; otherwise the UI designer has to go inside
the model.
John Boyer: I have a question about
that use case; is that something that the host language does? For
example, in XHTML, can't you style particular controls be
readonly?
Steven Pemberton: It looks like
readonly, but it's not readonly. It doesn't control the
response.
John Boyer: So if I make an HTML input
readonly?
Steven Pemberton: If you make its CSS
presentation readonly, it looks readonly, but it isn't.
John Boyer: So you have to go into the
control itself. I see.
Nick van: And extra constraints.
Charlie Wiecha: This sounds like a
good use case for multiple models; I could imagine a UI model,
provided we could solve the cross-model inclusion. I can see the UI
MIPs as a special case, but it's interesting to see how you do this
progressive tailoring.
Leigh Klotz: I like the progressive
tailoring using recursive models.
Charlie Wiecha: I think we should add
this to our use cases.
John Boyer: How would you get
different behaviors on different UI controls?
Charlie Wiecha: There may be different
UI properties; it's not clear they're MIPs.
John Boyer: I liked this more when it
was the model exploded out into the glass, with a centralized
formal model of data and MIPs. If someone wanted to adopt more of
the vocabulary when they wanted features they could; for example
binding two controls to the same data. At that point you may have
to rationalize your MIP declarations that are on those controls
into actual binds against the underlying data model. Factoring out
two nodes that have the same name implies declaring an instance and
binds and putting them in one place.
Charlie Wiecha: Making the implied
mechanism too sophisticated runs the risk of it being too hard to
understand.
John Boyer: I don't want to loose site
of Nick's goal of separation.
Leigh Klotz: It would be nice if a
model and a naive UI could be brought together without changing the
semantics of the naive UI, or having to make textual changes to
it.
Nick van: ...
John Boyer: Should we discuss more or
let Nick go on and stew on it?
Charlie Wiecha: Maybe there's an
incremental way to add explicit instances is a further twist. There
may this additive-compositional instance declaration where you
inherit the implied instance as well. It may get funky but it does
provide the incremental feature that Leigh was asking about. I'll
see if I can add some of that to the discussion that Mark and I are
doing.
John Boyer: Another thing on MIPs
on controls:
http://www.w3.org/MarkUp/Forms/wiki/Unified_evaluation_context
John Boyer: When someone gets to the
point of moving a calculate expression from a UI control to a bind,
it would be helpful if that could be done without having to change
the expression in any way. The key here is that if I'm writing an
input control: ... and not <input
name="result" calculate="../a + ../b">.... But with the
way we do bind context, you would have to do the dot-dot. This is
in some way a design flaw of calculate because it can have no
children.
Nick van: If you just want to sum the
preceding siblings you know what they are. If you're not on the
node you're on with the input, you loose that position in the
context.
John Boyer: With <data>
<a/> <b/> <result/> <a/> <b/>
<result/> </data> it's hard to compute the
second result.
Nick van: It's hard with flat XML. You
need to know where they are.
John Boyer: And we say with XForms you
can use your data as it is. I don't propose that we change the
default evaluation context for calculate, but it sure would be nice
to have an easy way to express it.
Nick van: Maybe with the context
attribute?
. The context attribute so far has only been applied to two things. It is applied to the in-scope evaluation context before anything else happens, for example in insert, it is evaluated before the nodeset. So in bind, it would be weird to have it evaluated after the nodeset. But the inner bind might be able to reset the inner context.
John Boyer: And use a nested bind: <bind nodeset="result"> <bind context=".." calculate="a + b"/> </bind>
John Boyer: I like that. <bind nodeset="result"> <calculate context=".." value="a+b"/> </bind>
Keith Wells: Could you have a
calculate on another instance in another model with this?
John Boyer: I hope not. I think it's
valuable to have them communicate, but it doesn't seem to be at
this level. It seems like "GOTO Considered Harmful" whereas we I
think we want to have whole subtrees.
Keith Wells: In dependencies, when you
pull in larger-scope models such as "post office," how do you work
out dependencies in nested models. Or there may be cases where
there are siblings. For example, relating a zip code to a
house.
John Boyer: So an outer model would
use the context attribute to use an instance with an id to drill
into an inner model instance.
Keith Wells: I wasn't thinking of the
outer model of a shared entity, but a shared entity.
Charlie Wiecha: That's the kind of
thing you need to let the UI designer deal with backend data
models.
John Boyer: So this is what I get
from Keith's example:
John Boyer: <model
id="outer"> <model id="inner"> <instance id="X"> ...
</model> <bind nodeset="result"> <calculate
context="instance(X)" value="a+b"/>
John Boyer: I have previously
coordinated the inner model.
Charlie Wiecha: Or you write the bind.
The point of coordination is the backend schema, which is the inner
model.
John Boyer: Oh. I get it now. Turn it
inside out. The UI designer is going to aggregate the data
architect's model and add other stuff to it.
Charlie Wiecha: Data to glass.
John Boyer: I was confused but now I'm
not.
Charlie Wiecha: So it's nested. The UI
designer aggregates the data architect's stuff and then the form
controls mark that up.
John Boyer: Nick, you said you were
interested in writing up the straw-man proposal for expressing MIPs
on UI. Would you also be OK with doing this topic or do you want
someone else?
Nick van: [irc] but isn't charlie
going to write something now?
John Boyer: Charlie is doing
behavioral changes to nested models. This was changes to
bind.
John Boyer: This is something I can do
if no-one else wants it. Charlie or Nick?
Nick van: I can do it.
Action 2008-01-23.1: Nick van den Bleeken to take on general topic of http://www.w3.org/MarkUp/Forms/wiki/Unified_evaluation_context but with changes as necessary.
Action 2008-01-23.2: Nick van den Bleeken on strawman proposal writing for http://www.w3.org/MarkUp/Forms/wiki/Add_model_item_properties_to_UI_level
Action 2008-01-23.3: Charlie Wiecha and Mark Birbeck to write strawman for http://www.w3.org/MarkUp/Forms/wiki/Nested_models_for_convenient_grouping_and_composition
John Boyer: Steven, Leigh, Erik,
please check your action item lists for items done.
Nick van: Did you see Mark Birbeck's
list? I did a triage and He agreed to it a couple of calls ago.
John Boyer: There's a strong desire
to use the word value here, but we already use it.
Nick van: [irc] default-value ;)
John Boyer: Anything we express at the
UI layer we ought to have at the canonical model. The hack we have
now is a pile of MIPs; readonly=false, calculate, conditional
logic, etc.
John Boyer: Does anyone have strong
opinions of what that attribute might be called.
Leigh Klotz: It's pretty clear it has
to be called value on the form controls.
John Boyer: The only place we have it
on form controls is on output; we have it on a host of actions, as
an XPath expression. On other controls it would be a string, not
XPath.
Nick van: [irc] don't like value,
because it isn't the real value, but the initial value
Steven Pemberton: [irc] initial=
Sebastian Schnitzenbaumer: [irc]
initial is cool too
John Boyer: What about when you save
the document and reload it?
Nick van: You don't want the initial
instance loaded it.
Sebastian Schnitzenbaumer: [irc]
Raggett have called it StartsWith or BeginWith
John Boyer: It gets the user data from
the last session and pushes that into the implied instance, and
that would overload the initial values?
Nick van: Just a submission that
replaces the instance.
John Boyer: That's not bad; express
the instance data.
Nick van: I like initial better than
value.
Charlie Wiecha: What's wrong with
default?
John Boyer: That's good too. Nick, can
you make any progress on this before the F2F?
Nick van: I have only one day.
John Boyer: The goal is to have the
plan for what we want in XForms 1.2 by the end of the F2F.