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
Steven Pemberton: We've been rechartered. The wrong charter link was published briefly, but it's correct now.
http://lists.w3.org/Archives/Member/w3c-ac-members/2010AprJun/0040.html
Steven Pemberton: When this re-opens, please ask your AC representative to vote for it. It's only editorial changes.
Steven Pemberton: Anyone reporting
completion?
Nick van: I will send in an updated
list before next call
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.
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.
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.
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:
do you look at the current context and if model is different from current switch?
Action 2010-05-19.1: Erik Bruchez to ask public-forms and www-forms implementors - When you switch models, to what context do you switch? root element or do you go back to the in-scope context? Please cite use cases that support your decision.
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.