Relevant also doesn't apply to setvalue and other actions, was Re: Draft minutes for 2007 August 15

With regard to the issue of whether the readonly MIP affects XForms 
actions, I mentioned today that model item properties in general were 
meant to be information that *form controls* should be compelled to obey, 
where XForms actions are not form controls.  Rather quickly I pointed out 
that the relevant MIP was another example of the problem we are having 
with readonly.  So quickly, that it happened between the minutes that were 
recorded :-)

I mentioned this in the context of the use of @ref in setvalue, so my 
point was that if setvalue were intended to consume MIPs as if it were a 
form control, then it would have to consume not just readonly but also 
relevant, which would mean you have no way of setting the value of a 
non-relevant node because the setvalue would have to be disabled. 

Yikes!  Not only is the spec clear that this isn't so, but also it does 
not even define setvalue as a form control.  Even stranger would be 
applying relevant to insert and delete in a manner analogous to how it 
works in repeat. Nowhere do we say that insert/delete should remove 
non-relevant nodes from the nodeset before proceeding with the 
interpretation of @at and @position.

Generally, single node bindings *used in form controls* communicate MIPS 
to the form controls, but the use of single node bindings and nodeset 
bindings in XForms actions is really just about referring to data needed 
to perform an action.

I think I also reiterated that violating the model's readonly MIP is also 
easy with the script interface from Section 7.  This and the point about 
non-applicability of relevant to setvalue, insert and delete are the 
foundation of my claim at the end that readonly is information to form 
controls only that they are required to respect.

Cheers,

John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





"Leigh L. Klotz, Jr." <Leigh.Klotz@xerox.com> 
Sent by: public-forms-request@w3.org
08/15/2007 09:09 AM

To
public-forms@w3.org
cc

Subject
Draft minutes for 2007 August 15






Please respond with comments or corrections.
Please start new threads for discussion.

W3C Forms teleconference August 15, 2007
* Present
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
* Agenda
http://lists.w3.org/Archives/Public/public-forms/2007Aug/0046.html 
Previous Minutes
XForms Conference at XML Conference
Need to review and incorporate Uli's changes
Finish deliberation on choose()
Inserts and deletes should not re-initialize inner repeat indexes
Problem with definition of readonly (1.0 and 1.1)
IRC Minutes
Meeting Ends
* Previous Minutes
http://lists.w3.org/Archives/Public/public-forms/2007Aug/0029.html
IRC supplement: http://www.w3.org/2007/08/08-forms-minutes.html 

* XForms Conference at XML Conference
http://lists.w3.org/Archives/Public/public-forms/2007Jul/0055.html 
http://lists.w3.org/Archives/Public/public-forms/2007Jul/0036.html 
http://lists.w3.org/Archives/Public/public-forms/2007Jul/0024.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.
* Need to review and incorporate Uli's changes
http://lists.w3.org/Archives/Public/public-forms/2007Aug/0008.html 
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
* Finish deliberation on choose()
http://lists.w3.org/Archives/Public/public-forms/2007Aug/0022.html 
http://lists.w3.org/Archives/Public/public-forms/2007Aug/0025.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.
* Inserts and deletes should not re-initialize inner repeat indexes
http://lists.w3.org/Archives/Public/public-forms/2007Aug/0038.html 
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/UI?id=21 
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.
* Problem with definition of readonly (1.0 and 1.1)
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/MIPs?id=176 
http://lists.w3.org/Archives/Public/www-forms/2007Aug/0000.html 
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.
* IRC Minutes
* Meeting Ends
http://www.w3.org/2007/08/15-forms-minutes.html