Blake Jones, ViewPlus Technologies/DAISY
Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Joern Turner, DreamLabs
Leigh Klotz, Xerox (minutes)
Lars Opperman, Sun
Nick van den Bleeken, Inventive Designers
Roger Perez, SATEC
Uli Lissi, DreamLabs
Kenneth Sklander, PicoForms
Keith Wells, IBM
John Boyer: Does anyone have
program funding to help defray travel and hotel costs for the
keynote speaker?
Charlie Wiecha: Should we assume the
proposals are accepted, or do we need pruning?
John Boyer: Good point; we had seven
submission and six slots plus a keynote, so we need to pick six of
the seven. I haven't tried to organize anything yet. The only
thoughts I've had so far is that we should go for variety; I
haven't looked at the submissions yet, but if anyone wants so, they
should. Is anyone who isn't a submitter make an assessment. Who
would that be? Probably Leigh, Nick
Nick van: [IRC] I don't think I can do
it.
Lars Opperman: I am here.
Leigh Klotz: We have to pick one paper
not to present. If there's nothing obvious, then maybe we should do
it by lot.
Charlie Wiecha: Yes, we could ask if
anyone wants to withdraw.
Leigh Klotz: Another possibility is
for two presenters from the same organization to combine.
John Boyer: Leigh, can you do
this?
Leigh Klotz: I'll come up with a
process for choosing.
Action 2007-08-8.1: Leigh Klotz to propose XForms day program committee paper choice process.
John Boyer: These are the changes for "homogeneous collections."
John Boyer: Approve? Erratum or
just 1.1? The insert and delete actions in XForms 1.0 have a
strange behavior that when a new row (repeat-item) is added or
deleted, obviously the index of the repeat is updated; there is an
extra step that says that any nested repeat indices are
re-initialized. I believe this is part of the "cruft" of not
understanding what repeat mean, the difference between the objects
being repeated and the runtime items. As explained to me, at the
time, there was a belief that there was only one inner repeat
object, just as there was only one switch object. This leads to
messy business throughout the spec. It's clear now that when you
have a nested repeat, there is a runtime object for each nested
repeat for each row. And the same way that switches for different
cases.
Kenneth Sklander: In principle I
agree; the one issue I have is what happens if you reference the id
from the index function? Otherwise I agree with everything you said
about that issue.
John Boyer: In XForms 1.0 and 1.1 [
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#idref-resolve]
there is a special section that addresses that question.
Kenneth Sklander: Yes.
John Boyer: So I'd say that's
how.
Kenneth Sklander: So if we adopt that
same thing for index function?
John Boyer: We already have; that's
what section four is talking about.
Kenneth Sklander: OK.
John Boyer: It says it's applicable to
all actions that use an id.
Kenneth Sklander: But index is not an
action.
John Boyer: It's applicable to
setindex, and likewise in the the third paragraph, it also says the
instance function and the index function as well.
Kenneth Sklander: OK. And the built-in
id function in XPath?
John Boyer: I think the id function
escapes because it is always referring to instance data, which is
never within a repeat.
Kenneth Sklander: Right. Is the
instance function used in a repeat?
John Boyer: I don't know why that's
there offhand.
Kenneth Sklander: Really it's only the
index function that references something in the UI, right?
Yes.
John Boyer: You have to consider both
where the invocation is happening and what is referenced.
Kenneth Sklander: What happens when
the DOM is exposed via getElementByID? You should return the
correct element.
John Boyer: I would agree that our DOM
is actually not that mature. Really the only thing that we give
access to from the XForms processor in section 7
Kenneth Sklander: Is the model
John Boyer: And the instance function.
It's broken for separate reasons; but the issue here is about
repeat index updates. So the question I put to everyone is: Is
there anyone who is unsatisfied with the following:
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-insert
step 8. The yellow changes aren't the issue nor are the first and
second red ones, it's the third red one. The following text is
removed "and the index of any repeat nested within an updated
repeat is re-initialized to the startindex of the nested repeat. If
the startindex is less than 1 the index is set to 1. If the
startindex is greater than the size of the homogeneous collection,
then the index is set to the size of the homogeneous collection."
There is the same language in the delete section.
John Boyer: If you insert, any nested
inner repeats, there indices remain in the states they were
in.
Erik Bruchez: Or would it be
implementation dependent?
John Boyer: That's a good question. I
put a note saying it did not change. So I didn't. But it is a
note.
Erik Bruchez: Suppose you had two
different indices and the user switches between company 1 and
company 2 without clicking on an employee; the user will change the
index of the current company. With the new behavior, we'll have the
index of the employee not changing.
John Boyer: These changes only occur
if you insert or change a node; if you switch focus, there is
already no change to indices of inner repeat.
Erik Bruchez: We don't specify
anything in that case.
John Boyer: I guess. We don't say that
they should change, so it seems that they shouldn't. Particularly
not if you're counting on it.
Erik Bruchez: It's not crucial;
especially if it's not specified. If you change a parent index
through user interaction and specify that the user indices don't
change, then it's kind of related, because it changes the parent
index.
John Boyer: I see your point, and in
9.3.7 I've missed the one in setindex, which also
re-initializes.
Erik Bruchez: We have insert, delete,
setindex, user interaction, and the tricky case of instance
replacement. Maybe we should centralize the behavior
separately.
John Boyer: That is the third part of
my issue #21. The description of repeat index changing doesn't seem
to belong in insert/delete, but in repeat.
John Boyer: ...
John Boyer: Parts 1 and 2 asked for
removal on insert and delete; now that I look at it I would ask the
same on setindex. When you mutate the index of an outer repeat,
that shouldn't have any impact on the inner repeat indices.
Leigh Klotz: Given the change we're
making the change to allow non-homogeneous repeats, does it
matter?
John Boyer: ...
Erik Bruchez: I'm not sure I
understand why this is a problem from a non-homogeneous
repeat.
Leigh Klotz: ...
John Boyer: ...
Erik Bruchez: When an inner repeat is
not focused, we don't have any way to access it.
John Boyer: You can setindex of outer
repeat to each value.
Erik Bruchez: So you can then read it
in that case. Good point. But I'm not very concerned. The user
won't see the index unless the form author does what John said to
expose it. I never had a use case for this. When you switch the
outer repeat index from to 1 to 2, what if you want the user to see
the nested index set to 1. Can you still do it? But I don't have a
use case.
Nick van: What happens with indices in
repeats that are not in the active row when you do inserts on
active rows?
John Boyer: That's a great question.
In delete, only if the index changed as a result of the deletion
would the inner repeat indices changed. So it was kooky.
Erik Bruchez: I think Nick's question
is different. I have a nested repeat and three iterations of the
outer repeat. Somewhere I store the three iterations. Do I delete
it if I remove that information?
John Boyer: My interpretation is that
you are allowed to discard it. For each inner repeat that is
actually generated you get a runtime object that is supposed to
represent the entire row of the outer repeat. That object is
responsible for all UI objects in that row including the inner
repeat. It contains the context, the context node. It generates a
bunch of UI controls such as the inner repeat on that row. When you
delete that outer row, you delete that object and all the inner
controls including the runtime objects for the inner repeats.
Erik Bruchez: I think that would make
sense. Now when you go from 2 to 3, the outer repeat index is now
3. What is the index of the new inner repeat? Startindex? Must be
within bounds.
John Boyer: I think there could be
better wording around it, but whenever you create it (UI init or
mid-life) they behave as they do when you initialize them.
Erik Bruchez: ...delete and
insert...
John Boyer: That's challenging if you
delete and row and insert a row, because you have to check that row
to make sure it's the same, by happenstance, in special homogeneous
collection cases.
Erik Bruchez: You could have index 3
point to employees and in the same repeat, it could point to the
3rd office in the building, in non-homogeneous collections.
John Boyer: OK. Does everybody feel
pretty comfortable with getting rid of the inner repeat
re-initialization that's happening in the spec?
Erik Bruchez: I still have this little
issue that when the outer index changes through user interaction,
would means would you have to reset the inner index. In insert, you
are in an action and can do a setindex. If it is through a user
interaction, we have no event for catching the index changed.
John Boyer: The setindex action
case?
Erik Bruchez: The user interactively
changing the index of an outer repeat.
John Boyer: So you go to a new row,
and the user clicks on that row, you would expect that by virtue of
clicking there that it would re-initialize the focus of the repeat
on the same row.
Erik Bruchez: Not if you click on a
text area; some implementations may only react to form controls and
that's not a problem.
John Boyer: When you click into the
text area that changes the index of the outer repeat. You want the
inner repeat to be re-initialized?
Erik Bruchez: That would be the
idea.
John Boyer: Why?
Erik Bruchez: It's just a possibility;
I don't have the use case. That's the behavior we had in XForms
1.0.
John Boyer: When you change index of
outer repeat, do you did an explicit setindex?
Erik Bruchez: That's exactly the
idea.
John Boyer: And that resets the index
of every inner repeat on every row?
Erik Bruchez: Not in XForms 1.0
because you have only one index for the repeat. Now you need
multiple ones; that is what you are trying to change.
John Boyer: Actually, in XForms 1.0TE
and maybe in SE, we don't have the case that there is only one
runtime object for any UI control that is repeated. If a UI control
is repeated, it gets a runtime object for each copy.
Erik Bruchez: I agree with that. But
in many user implementations, if I see three employees, I don't
necessarily see which one has the focus; you can't have two at the
same time. Even with the changes you propose now, it's still an
option to have a single control have an indicator; we are just
talking about how to store the focus information. It's not a user
focus. The keystrokes will not be directed to invisible
controls.
John Boyer: The index is not the
focus. It is an additional piece of information.
Erik Bruchez: Sure. But if we
reinitialize the inner repeats then it is as if you had only one
piece of information.
John Boyer: Yes, that's what I'm
trying to fix. We don't have it for switch anymore.
Erik Bruchez: I think it is good to
define how switch in repeat works. But what if you want to stay
compatible with what you had before?
John Boyer: ...
Erik Bruchez: ...
John Boyer: So could we tolerate this
as an 1.0 erratum? We said switch works in repeat in 1.0, with
every switch on every row getting its own case. As a matter of
consistency, every repeat on every row gets its own index.
Erik Bruchez: You can't toggle a case
through the UI without clicking,
Kenneth Sklander: [departs]
Leigh Klotz: You can do it through
submission response and toggle.
Erik Bruchez: It always requires the
toggle. But with setindex you can do it without clicking
around.
John Boyer: I can use a repeat with an
xpath predicate that looks like a switch and it wouldn't act like
that.
Leigh Klotz: Do you actually do this
evil thing?
John Boyer: No
Leigh Klotz: Just asking.
John Boyer: I'm surprised this took this much time. Do we want to keep the ones in setindex? Just update them on the target row? Please send mail on this so we can get it done by next week.