- From: David Landwehr <david.landwehr@picoforms.com>
- Date: Tue, 19 Jun 2007 22:29:51 +0200
- To: John Boyer <boyerj@ca.ibm.com>
- Cc: public-forms@w3.org
- Message-Id: <C1259374-16C6-416C-8325-7446F4F126A2@picoforms.com>
I have accepted the resolution, please don't reopen! I apologize for my very blunt statement about ignorance, it was uncalled for. Best regards, David On Jun 19, 2007, at 9:05 PM, John Boyer wrote: > > Hi David, > > Although it was appropriate for your response to go to www-forms- > editor, note that I have moved the discussion to public-forms as > that is appropriate for further discussion of the issues. > > I agree that I do not know of the specific optimization you have in > mind, but I don't recall that you have ever explained the > optimization so that it can be assessed by the group. This makes > it difficult to make an exception to the previously defined behavior. > > We have a very useful use case articulated and even added it to the > spec to resolve the non-clarity aspect of your feedback. To adopt > the specific technical solution you wanted would require > eliminating that use case, but in favor of an unspecified > optimization. > > Despite not knowing the specifics of your optimization, I do not > believe that my statement that "I don't think you can do that kind > of isolation" is borne of ignorance. > > You cannot see it from the machine-formatted minutes, but if you > look at the underlying IRC minutes (http://www.w3.org/2007/06/13- > forms-irc), you will see that we spent 1.5 hours on this one issue, > which was a very large amount of time on this one issue, especially > considering that we were facing on the order of 150 last call > issues to discuss. Considering that we made it through about half > during the three days, it should be clear that your issue received > many times the average amount of consideration. The minutes do not > reflect the amount of effort that the working group devoted to your > issue because it was a lengthy discussion about many complex > aspects of the existing specification. > > More specifically, my own claim that "I don't think you can do that > kind of isolation" is based on the fact that I think can create > legal XForms that will break your optimization without setting a > calculated node to readonly false (if setting a calculated node to > readonly false breaks your optimization). This is based on the > fact that the setvalue action can change a node marked as > readonly. Readonly is a property that is communicated to the UI > via *notification* events. Just as non-relevance does not make > data nodes unavailable to XForms actions, readonly does not make > them immutable via XForms actions. Hence, I can use setvalue at > will to manipulate a readonly calculated node just as if it were > not readonly and manipulated by a UI binding. Put another way, the > readonly is information that affects the state of form controls > only, which is in principle unrelated to the formation of > computational dependency graphs and subgraphs and in practice > unrelated due to the existence of the XForms setvalue action. > > In conclusion, it would help to know more about your specific > optimization since there *may* be some other way to accommodate it > or something like it. Either way, I hope you will understand from > this email that the whole working group does take your feedback > very seriously as you are an esteemed member of this working group > even if this particular issue did not turn out according to your > expressed preference. > > Sincerely yours, > 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 > > > > > David Landwehr <david.landwehr@picoforms.com> > Sent by: www-forms-editor-request@w3.org > 06/13/2007 11:31 PM > > To > John Boyer <xforms-issues@mn.aptest.com> > cc > www-forms-editor@w3.org > Subject > Re: Last call comment about readonly property with calculate (PR#45) > > > > > > > I have read through the minutes and it seems you don't even > consider my > request. The statement by John "I don't think you can do that kind of > isolation." clearly displays the ignorance from which the > decissions are > made in the working group. > > I accept the resolution simply because I give up. > /David > > John Boyer skrev: > > We agree it was unclear, but we find that calculate merely > defaults readonly to > > true, and that it can be set to false, and that there are use > cases, namely > > default value. We tested the use case and found it works. We > changed the note in > > 4.3.6 [ http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index- > diff.html#evt-recalculate] > > and put an example in MIP for readonly [ > > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index- > diff.html#model-prop-readOnly] > > > > Please let us know if this resolution is acceptable. > > > > Thank you, > > The Forms Working Group > > > > > >> Having the following: > >> <xf:model> > >> <xf:instance> > >> <data xmlns="">value</data> > >> </xf:instance> > >> <xf:bind nodeset="." readonly="false()" calculate="1"/> > >> </xf:model> > >> > >> It is not spelled out in the specification that it is possible to > >> override the default state when it has a calculate on it. The > default > >> value is true() when the node has a calculate on it. On the > other side > >> it is not specified that it is not allowed. I think it should > not be > >> allowed since it is not clear when the value will be recalculated > >> because a node cannot take itself as dependent. E.g. an insert > or delete > >> will recalculate the value even if the user has updated the > value (this > >> must also happen if an insert happens in another instance). This > could > >> be a problem for implementation which isolates the creating of > >> dependencies between instances. > >> > >> Best regards, > >> David > >> > >> > >> > > >
Received on Tuesday, 19 June 2007 20:30:30 UTC