W3C Forms teleconference January 23, 2008

* Present

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

* Agenda


* Previous minutes

* Rich Web Application Backplane


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.

* F2F

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.

* Yahoo!


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.

* Input Mode Issues

* Related to model update

http://www.w3.org/MarkUp/Forms/wiki/Nested_models_for_convenient_grouping_and_composition http://www.w3.org/MarkUp/Forms/wiki/Externally_defined_models_with_src_attribute

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.

* MIPs on controls

http://www.w3.org/MarkUp/Forms/wiki/Add_model_item_properties_to_UI_level http://www.w3.org/MarkUp/Forms/wiki/Unified_evaluation_context

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?

John Boyer: And use a nested bind: <bind nodeset="result"> <bind context=".." calculate="a + b"/> </bind>
. 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.
Leigh Klotz: Or use a calculate child. This is the solution I alluded to earlier with the combinations.

John Boyer: I like that. <bind nodeset="result"> <calculate context=".." value="a+b"/> </bind>

Leigh Klotz: This gives you the freedom to put the combinator attributes on as well.
John Boyer: That looks rather neat. I've longed for this for on constraint as well. It would help with re-authoring.
John Boyer: ...
John Boyer: So this helps solves the context issue transformation between glass and data syntax for MIPs.
John Boyer: The other issue is when you want to bind two controls to the same node doesn't come up until after the transition because the transformation to the data model would create two nodes with the same name.

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.

* Default values on controls


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.

* IRC Minutes


* Meeting Ends