RE: Conclusion to effects of readonly on trigger

Sorry I missed today's call.

One way to think of readonly vs relevant on things like triggers
based on XForms' model-centric design:

enabled trigger == the rendered control is actually wired to
something.
readonly == the bound  data item  is  readonly 

So for instance, it makes perfect sense to bind a repeat to a
nodeset containing 20 nodes,
and have the  repeat displaying upto 5 items, and to have
triggers that scroll the repeating list.

Now, if an input control (or any other control that mutates data
 )
 is bound  to a data node that is readonly  then that control
 becomes disabled -- but it's not purely a consequence of MIP
 "readonly" -- but rather as a consequence of two bits:

A)  Control mutates data
B)  Bound data is immutable 

Thus, an input control that is bound to a readonly node can
essentially become an output control.


Klotz, Leigh writes:
 > John,
 > Here's my opinions on this summary:
 >  
 > I think the key thing we came up with was that, unlike the recent notice
 > that disabled form controls don't receive events, we are *not* going to
 > say that about trigger bound to readonly node. That appears to be point
 > 1.  We also decided that readonly has no effect on trigger's behavior in
 > other unspecified ways, so that's point 2a.
 >  
 > As for point 2b, Im not sure a "countenance".  If it means style, and
 > the host language supports some styling mechanism such as CSS, an author
 > (or user agent default) can certainly style it however desired.  Our
 > informative CSS3 style sheet does show anything for xf|trigger:readonly
 > but I don't see how we can proscribe it.  (I think Mark Birbeck made the
 > argument that we should avoid saying anything about presentation here,
 > but maybe I'm confused.)  
 >  
 > I'd be happier to see these two responses split up:
 > - Put (1) and (2a) in the spec document as an inforamative note.
 > - The body of (2) remains where it is (the minutes, this discussion) but
 > not in the spec document.
 > - Change 2b to an email response and say we aren't putting anything in
 > our informative CSS style sheet section for xf|trigger:readonly.
 >  
 > I suspect that some implementations might use XBL or some other
 > customization mechanism to take advantage of the readonly MIP or the
 > :disabled CSS pseudo-property to affect behavior, and again, while we
 > might think it's unclean to do so, we can't really prohibit it; at the
 > same time, we have recognized the request already for extensible MIPs
 > for use in styling and XBL binding, so I don't think we need to act
 > further on this for XForms 1.1.  In other words, those who have XBL or
 > their own extension mechanism are allowed to warp trigger:disabled
 > behavior and style, but should know that it's not the path going
 > forward, and they probably want to pay attention XForms futures for
 > extensible MIPs.
 >  
 > How does this all sound?
 > Leigh.
 >  
 >  
 > ________________________________
 > 
 > From: public-forms-request@w3.org [mailto:public-forms-request@w3.org]
 > On Behalf Of John Boyer
 > Sent: Wednesday, May 02, 2007 12:53 PM
 > To: public-forms@w3.org
 > Subject: Conclusion to effects of readonly on trigger
 > 
 > 
 > 
 > I think we were pretty close to a conclusion on the telecon about the
 > interpretation of the readonly MIP for trigger. 
 > 
 > Whatever the decision, it seems worthwhile make note of it in the spec
 > given that we had some work to do getting through the points ourselves. 
 > 
 > Let's see if we can get this wrapped up on the list during the week
 > and/or get a clear statement of resolution that folks can vote on next
 > week if necessary. 
 > 
 > Here is what I understood from the discussion: 
 > 
 > 1) Like all other events for MIPs, the xforms-readonly and
 > xforms-readwrite events are received by a trigger bound to a node (when
 > the processing model says those events are to be dispatched, of course).
 > 
 > 
 > 2) The readonly MIP is a statement about the what can happen to the data
 > node.  Since a trigger does not directly manipulate the data node via
 > its UI binding, there is no direct relationship between the data node
 > being readonly and presentational properties of the trigger.
 > Specifically, 
 > 
 > a) The ability to activate a trigger is not disabled if the trigger is
 > bound to a readonly node 
 > b) The default countenance of the trigger is unaffected, i.e. it does
 > not take on a disabled countenance 
 > 
 > 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
 > 
 > 

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Wednesday, 2 May 2007 23:41:32 UTC