- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Thu, 16 Aug 2007 10:01:40 +0100
- To: public-forms@w3.org
Of course that makes sense.
I can't imagine the puzzle for both authors and implementors if setvalue
had to look at MIPs, because you would like the MIP information to be
reliable, that is up to date. But actions including setvalue can run at
any time, including before recalculate, and after recalculate, in other
words between actions that will indirectly change the MIP values. There
is a good chance that the node's MIPs will be out of date, and you would
have to perform recalculations all the time to fix it.
Plus, I really don't see why we would want to do this in the first place.
-Erik
John Boyer wrote:
>
> 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*
> *** <#topic0>* 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
> *** <#topic1>* Agenda*
> _http://lists.w3.org/Archives/Public/public-forms/2007Aug/0046.html_
>
> * _Previous Minutes_ <#topic2>
> * _XForms Conference at XML Conference_ <#topic3>
> * _Need to review and incorporate Uli's changes_ <#topic4>
> * _Finish deliberation on choose()_ <#topic5>
> * _Inserts and deletes should not re-initialize inner repeat
> indexes_ <#topic6>
> * _Problem with definition of readonly (1.0 and 1.1)_ <#topic7>
> * _IRC Minutes_ <#topic8>
> * _Meeting Ends_ <#topic9>
>
> *** <#topic2>* 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_
>
> *** <#topic3>* 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.
>
> *** <#topic4>* Need to review and incorporate Uli's changes*
> _http://lists.w3.org/Archives/Public/public-forms/2007Aug/0008.html_
>
> *_Action 2007-08-15.1:_* <#ACTION1>* John Boyer to review and
> incorporate on Uli's changes
> **_http://lists.w3.org/Archives/Public/public-forms/2007Aug/0046.html_*
>
> *** <#topic5>* 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:_* <#ACTION2>* 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:_* <#resolution1>* For XForms 1.1 we deprecate
> if, make choose return objects, and make the minor editorial changes to
> choose.*
>
> *** <#topic6>* 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:_* <#resolution2>* For
> **_http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/UI?id=21_** we
> accept.*
>
> *_Action 2007-08-15.3:_* <#ACTION3>* 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.*
>
> *** <#topic7>* 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.
>
> *** <#topic8>* IRC Minutes*
> *** <#topic9>* Meeting Ends*
> _http://www.w3.org/2007/08/15-forms-minutes.html_
>
--
Erik Bruchez's Ponderings
http://erik.bruchez.name/
Received on Thursday, 16 August 2007 09:01:52 UTC