Blake Jones, ViewPlus/DAISY
Charlie Wiecha, IBM
John Boyer, IBM (chair)
Joern Turner, DreamLabs
Leigh Klotz, Xerox
Mark Birbeck, x-port.net
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C
Mark Seaborne, DreamLabs
Keith Wells, IBM
Lars Opperman, Sun
http://lists.w3.org/Archives/Public/public-forms/2007Aug/0029.html
John Boyer: I may be able to help
with travel expenses for the speaker. We have 6 slot and 7
speakers. I sent ask.
Leigh Klotz: I sent a note to Steven
and Sebastian about my action to come up with a process. I have
some ideas, some maybe hair-brained, and I want to go over them
first.
Charlie Wiecha: Maybe some of the
could be turned into a panel.
Action 2007-08-15.1: John Boyer to review and incorporate on Uli's changes http://lists.w3.org/Archives/Public/public-forms/2007Aug/0046.html
John Boyer: I think we can come to
a resolution without Erik based on the mailing list. I'd like to
ask for what Erik wants. Erik's basic proposal was that the type
rationalization in the choose function be eliminated. We found that
the revering to the nodeset version is insufficient; the object
version is better. I found it compelling that we need a choose
function, because we need to deprecate the if() function and
encourage people to migrate over to the choose function because of
the collision with the if construct in XPath 2.0. The choose
without type rationalization seems to be the most forward-looking.
Keeping it is better than getting rid of it; the object form trumps
the nodeset form, and dropping the type rationalization makes
sense. It answers multiple last call comments from Michael Kay and
Erik.
Nick van den Bleeken: We aren't 100% compatible if
we don't use type rationalization, because in XPath 2.0, only the
true/false expression is evaluated.
John Boyer: We won't be 100%
compatible, but we'll have to solve that problem when we move to
XPath 2.0. Frankly it might mean that the choose function
survives.
John Boyer:
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#fn-choose
John Boyer: The first sentence
("object version") resolves a last-call comment from Steven. The
type rationalization is dropped by Erik's request. I added some
notes as well.
Leigh Klotz: I think we ought to just
go ahead and say what the issue is in the note.
Nick van den Bleeken: [irc] can't we deprecate if
then? in xforms 1.1?
John Boyer: I want to make sure the
deprecation language is OK with the group, but making the issue
stronger is ok.
Steven Pemberton: [IRC] good idea. so
there should be a comment in the section on if(). Oh! It is already
deprecated
Mark Birbeck: choose() still refers to
if.
Steven Pemberton: This function
provides a replacement for the if() function that uses objects
instead of strings.
Mark Birbeck: I've been in the past
torqued out by all three of those arguments being evaluated; is
there any merit of it being pointed out?
John Boyer: I can make another note
there. I believe that's also a property of XPath 2.0, that function
parameters get evaluated. That's probably why it's not a
function.
Mark Birbeck: Yeah, it's an operator
kind of thing.
Nick van den Bleeken: If you replace if with
choose, then you have no string conversion, so we need another
note.
John Boyer: Unless the context in
which it was being used required a string. You need string around
it. That may be unexpected for some people.
Action 2007-08-15.2: John Boyer to make wording changes in http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#fn-choose to amends notes, first sentence of description, and add notes as described in minutes and look for occurrences of if() throughout spec, including examples.
John Boyer: Is there anyone opposed to deprecating if, making choose return objects, and making the minor editorial changes to choose?
Resolution 2007-08-15.1: For XForms 1.1 we deprecate if, make choose return objects, and make the minor editorial changes to choose.
John Boyer: Approve? Erratum or
just 1.1?
John Boyer: For some strange reason we
reset the inner repeat indices (my bias). I don't view inner
repeats and their index information being any different than inner
switches and the knowledge of what case they're on. My last call
comment is that we should get rid of this behavior from insert and
delete, and now it's apparent setindex as well. Erik's response was
that he agreed and it was a better behavior overall, though he asks
for better clarification than just modifying the three actions, for
example on focus change. Also a comment in the repeat section on
instance replacement. Down at the bottom of his email, I did
comment that Erik's major concern was that he didn't want to have
no way of doing the 1.0 behavior, so I suggested that to a large
extent what people wanted out of the 1.0 behavior could be done
with a DOMFocusIn, but if we wanted a repeat index change action,
that isn't hard to do.
Leigh Klotz: I added scroll-first and
scroll-last for implementing windowed paging view of, say, a
corporate address book. Coupled with @if on actions, these could be
useful pre-fetch.
John Boyer: Indeed the name scroll
would be used in the events. How about switch? Will we be asked for
events?
John Boyer: You get xforms-enabled
don't you on groups?
Mark Birbeck: You get xforms-select
and xforms-deselect. You can listen on the target and parent. If
you have a select inside a repeat, doesn't it apply to the
row?
John Boyer: Yes, except that with a
switch, we have case as target of select. With repeat, we have an
implicit root element called group, so people can't listen on that
as it has no id. I suppose if you threw an action inside the repeat
and listened for xforms-select, you get into the interesting waters
of eventing in repeat. If you dispatch an event to the explicit
group element and in a repeat element an action that listens to
that element by default attributes it would attach to that implicit
object. Events don't flow between the DOMs. If you do put an action
handler as a child of repeat, that will also attach to the repeat
element itself, when the document originally loads. When the
subordinate DOMs are created for the runtime elements then it
attaches there.
Mark Birbeck: I think it depends on
whether the repeat is a parent, or along side in another
tree.
John Boyer: The repeat is the parent
in the original DOM.
Mark Birbeck: You don't get events
processed inside instances, for example. ...
John Boyer: XML Events doesn't say
anything about not processing the whole document. So if repeat and
the instance are exceptions then we should say that. Then you
wouldn't be able to listen on the repeat.
Leigh Klotz: That's similar to the
basis of comments we got from Andrew Watt on XForms 1.0, that he
felt that XPath required us to have the XPath expressions refer to
the host document, and not the separate instance DOM. There's a
parallel with what you're saying here on XML Events.
Mark Birbeck: You could load and then
remove from the initial DOM tree.
John Boyer: I haven't had a problem
with the event handler run on both the item and the repeat or the
itemset, as long as the events don't flow between the two
DOMs.
Mark Birbeck: The same is true with
CSS. Subsumed into the parent, or retained.
Steven Pemberton: We defined XForms
1.0 to be DOM independent.
John Boyer: DOM Events wouldn't work,
or I don't see how.
Mark Birbeck: I can't see how but we
would have to define it.
John Boyer: We refer to XML Events 1.0
and it talks about how to propagate in a DOM, not across DOMs, nor
does our spec. Therefore events don't move between DOMs.
Mark Birbeck: We also don't say that
template expansion (repeat) says that it's done via DOM
expansion.
John Boyer: To make the events in
repeat work, it's clear to me that you have to expand into runtime
object (I don't want to say DOM). We have this same issue without
adding a new event. I said in this message that you can put a
DOMFocusIn handler inside the repeat and any form control inside
the repeat item will get it, and it will bubble up to the implicit
group. The only hiccup was that some implementers said that if you
clicked in the group but outside the form controls that the repeat
item index would change but you get no DOMFocusIn. To me it's a
little questionable about whether you need DOMFocusIn.
Leigh Klotz: So you listen for
DOMFocusIn and then examine the index?
John Boyer: Yes. So the overall
question is whether we can get rid of the repeat index
re-initialization and we've got all the machinery we need to do
that. Erik's not here but we've got his email. I want to ask the
group. Are there any objections to getting rid of this repeat index
reinitialization?
Joern Turner: [IRC] +1
Mark Birbeck: No. As long as authors
know. They can work around it if they want with DOMFocusIn.
John Boyer: OK, so no objections.
Resolution 2007-08-15.2: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/UI?id=21 we accept.
Action 2007-08-15.3: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/UI?id=21 John Boyer and http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/UI?id=21 John Boyer to implement spec changes and paste 0038 into issue 21.
John Boyer: If a node is readonly,
it says we don't allow changes. Then it says we don't allow value
changes. Then you look at DOM access in section 7 (inappropriately
placed) and we give unrestricted access. There's also xforms-insert
and xforms-delete, xforms-setvalue. What do other implementers do,
does ref imply respect for readonly?
Mark Birbeck: We have the model
protect the value and controls don't reflect the readonly. It
should be styled but we haven't done it.
John Boyer: The model protects it, but
what about calculate and what about actions? calculate makes it
readonly by default.
Mark Birbeck: I believe it's a mistake
to allow ways to change readonly values. Kenneth and David have no
getinstance.
John Boyer: There's two different
paths. One is that readonly is part of a set of MIPs and the model
is the property broker that are consumed by views and that actions
as part of the controller can do whatever they want. Or, we can say
that actions must respect the readonly MIP, but we'd need to do
something about our current DOM interface.
Mark Birbeck: It's a candidate for 1.2
work.
John Boyer: The upgraded DOM
interface. But right now it's just that it's unclear what readonly
applies to. What do other implementers do? Can you insert and
delete into readonly or does readonly only protect leaf
nodes?
Mark Birbeck: Hmmm.
John Boyer: Let's not go over this
time.
Leigh Klotz:
http://lists.w3.org/Archives/Member/w3c-forms/2002JulSep/0277.html
is the set of messages that led us to making calculate
readonly.
John Boyer: Or that calculate defaults
to readonly now.
Charlie Wiecha: ...
Lars Opperman: Or could we say that
calculate is the exclusive way of modifying a readonly node.
John Boyer: Or that readonly is a
piece of information for the views, as relevance.
Lars Opperman: An access modifier for
an object.
Leigh Klotz: You also have to allow
instance replacement readonly so it can't be a sole
exception.
John Boyer: I think actions should be
able to modify nodes and readonly subtrees. Please talk next week
or defer to the F2F.