W3C Forms teleconference May 19, 2010

* Present

Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C
Leigh Klotz, Xerox
Charlie Wiecham, IBM
Philip Fennell, MarkLogic
Erik Bruchez, Orbeon
Uli Lissé, DreamLab

* Agenda


* Previous Minutes

* Rechartering


Steven Pemberton: We've been rechartered. The wrong charter link was published briefly, but it's correct now.

* XHTML Modularization


Steven Pemberton: When this re-opens, please ask your AC representative to vote for it. It's only editorial changes.

* Action Item Review


Steven Pemberton: Anyone reporting completion?
Nick van: I will send in an updated list before next call

* Upcoming F2F

Steven Pemberton: Do we want a F2F before TPAC in November? Maybe once we get new members. Any opinions?
Charlie Wiecham: With the summer approaching, it may be close to November.
Steven Pemberton: Originally March would have been the first meeting of the new group. Amsterdam is always open if we feel like meeting.
Charlie Wiecham: Maybe in June, but new members might need more time.

* Workshop on Future Standards for Model-Based User Interfaces


Steven Pemberton: It was two days in Rome. It was the next step after the XG on the same topic. http://www.w3.org/2005/Incubator/model-based-ui/XGR-mbui-20100504/
Steven Pemberton: It was mostly academic attendees, but it was lead by Spanish firm Telefoncia. I think there were too many presentations, and the discussion time was meager, considering that there was already an XG. The discussion didn't get to concrete next steps for a WG. I was surprised at the broadness of the presentations and interpretations of "model." There was a lot about task analysis, user models, timing models. I gave a talk about XForms, and many presentations were about systems that used XForms. Unfortunately, I felt I hadn't gotten far enough to write a charter by the end of the meeting if it were up to me. It will be interesting to see if they produce a proposed charter.
Charlie Wiecham: What did Mr. Raggett say?
Steven Pemberton: He chaired it and chaired the XG. He said there could have been a third day for discussions.
Charlie Wiecham: What was the general view of the model / runtime relationship? It seems modeling is a large leap.
Steven Pemberton: HTML was seen as the last presentation layer, not the stuff they were taking about, but just one target of the abstraction. There was one interesting demonstration of a system reverse-engineering HTML and Javascript into a model (i.e., ordering a book), stopping in the middle, and re-targeting it to another device.
Charlie Wiecham: That's the Plastic UI?
Steven Pemberton: The middle part is interesting (the abstract) if there were a standard. There was more about SMIL and XForms, because of the abstract model. I don't think anyone mentioned SVG. There was an interest in having XForms as part of the big picture, and XForms would be an intermediate abstract UI layer with a concrete layer with HTML below.
Steven Pemberton: I'll send on the final report when I hear of it.

* XHR Last Call Comments

Leigh Klotz: We made our comments, and I don't think they're going to do anything.
Steven Pemberton: So do we respond that it's not good enough?
Leigh Klotz: I'm not sure that there is anything they're going to do.
Steven Pemberton: In their disposition of comments, they'll have to say that we said we can live with it or not.
Leigh Klotz: We're not happy.
Steven Pemberton: Then I'll make it clear in the WebApps group that we're not satisfied when they produce the disposition.
Leigh Klotz: We just can't continue with the email thread saying the same thing over and over.
Steven Pemberton: I'll report that we're not satisfied then.

* model and bind

http://lists.w3.org/Archives/Public/public-forms/2010May/0008.html http://lists.w3.org/Archives/Public/www-forms/2010May/0012.html

Erik Bruchez: Alain's answer pointed to the default model as the answer. Some groups then bind to the first instance of the first model, and within that group, it binds by ID to an element in the second model; then it reverts via @model to the first model. Is it OK to bind by id to something in a different model? I assume that's yes.
Nick van: I'm not sure if it's possible according to the spec. I'd like it to be.
Erik Bruchez: I'm not 100% sure either. I didn't find that it was impossible.
Erik Bruchez: Implementations allow it; we do and Alain said his does.
Erik Bruchez: http://gist.github.com/404511
Erik Bruchez: Then the quesion is what happens
Uli Lissé: http://gist.github.com/404511 is correct; without nested elements.
Erik Bruchez: So can it be determined statically with ancestor elements, or is there a dynamic aspect? In our implementation, we assume it is static. But it seems like it is dynamic because you have to look at the context to see if you're going to switch model.
Charlie Wiecham: And to the previous context for model1.
Steven Pemberton: Is there something to discuss or is this resolved?
Erik Bruchez: If we think we're happy with the behavior Alain describes, I'm reasonable happy. I don't expect controversy.
Leigh Klotz: What lines?
Erik Bruchez: Line 21 is model 1. Line 22 changes to model 2. Line 24 switches back to model1.
Leigh Klotz: Line 24 is statically determined.
Erik Bruchez: Yes. I had something slightly harder with variables because we have it in XForms 1.1. But you could have a variable in line 22 ref="$x". You could still analyze the XPath expressions, but that may be hard.
Leigh Klotz: Binds are lexically contained within models, so even predicates don't change.
Erik Bruchez: Right, but there are extension functions that allow model id to be specified for instance access. So there are ways that implementors can extend it.
Leigh Klotz: So it's statically determined unless you have cross-model functions or variables.
Nick van: modelAuthor-optional XForms Model selector. Specifies the ID of an XForms Model to be associated with this binding element. This attribute has no meaning for the current binding element when a bind attribute is present. Rules for determining the context XForms Model are located at 7.2 Evaluation Context.
Nick van: (second sentence assures that you can use bind to switch model)
Uli Lissé: I don't understand the issue; the binding context has @model, or it inherits the parent. With @bind you know the model. Even with dynamic parts, you know the context.
Erik Bruchez: I have no problem knowing what to evaluate. I was assuming it was statically determined. But that isn't completely true with extension functions. When you see the model attribute, you must look at the evaluation context node, and if it belongs to the same models, then you don't do anything; however, if they are different models, then you switch to the first node of the first instance of the model.
Charlie Wiecham: Why not inherit the previous evaluation context of that model? You've already got an evaluation context for that model, which may not be the root node.
Erik Bruchez: That was originally my understanding.
Charlie Wiecham: So do we contradict that now in the spec?
Nick van: I think so.
Charlie Wiecham: Maybe that's more predictable in the static sense.
Erik Bruchez: Is that a contradiction?
Charlie Wiecham: It depends on what we intend.
Leigh Klotz: What do you implement, Erik?
Erik Bruchez: I inherit the context. As you interleave model elements, we get get back to the last context via a stack. It's as if whatever you had in between didn't happen.
Charlie Wiecham: That's what I was thinking.
Leigh Klotz: Do we know that the spec says don't do that?
Charlie Wiecham: Section 7.2?
Erik Bruchez: I think there is something that contradicts it.
Erik Bruchez: "if the binding element expresses a model attribute that refers to a model other than the one containing the context node, then the context node of the in-scope evaluation context is changed to be the top-level document element node of the default instance of the referenced model, and the context position and size are changed to 1."
Charlie Wiecham: That seems to contradict it. That's too bad. I wonder what the motivation was.
Erik Bruchez: Exactly. I hadn't realized this was there.
Leigh Klotz: We should see what has been tested and implemented; it may be that the spec is wrong here.
Erik Bruchez: I remember asking the WG in the past.
Leigh Klotz: Initially models had only one instance; then we added multiple instances. We used them for select itemsets and copy, but then that got outlawed. We lost track of what they were for, except for multiple unrelated forms per page.
Erik Bruchez: John said portlets. The behavior for interleaving should be clear.
Charlie Wiecham: We should see what other implementors do, as Leigh said.
Leigh Klotz: Erik, would you write that up or should someone else?
Erik Bruchez: Do we have only the question about interleaving model attributes? There are three questions:

* @incremental and @delay


Leigh Klotz: This is motivated by the use case of @incremental.
Nick van: Right now the implementation could do that. A delay could be device dependent.
Charlie Wiecham: You might want different delays on different network configurations.
Steven Pemberton: The first network lookup should define your delay.
Leigh Klotz: If you get one event per character with submissions they'll stack up.
Nick van: If your processor runs on the server, you don't want to send every keystroke. We need to be careful not to say too much.
Leigh Klotz: What we say now isn't enough guidance. Is @delay max saying too much? Is it too weak to be useful?
Nick van: The name isn't good. Is it maximum or minimum delay?
Leigh Klotz: If we named it something like minimum-delay is it still too weak?
Steven Pemberton: What value do you use? A time limit isn't the right thing. Maybe with a network blockage you want a different number; you want it in terms of behavior.
Leigh Klotz: The only way to prevent congestion is end-to-end as you said.
Steven Pemberton: We can think and discuss it more next week.

* IRC Minutes


* Meeting Ends