Re: validity notification on intial or hidden data

  Dear John,
   I apologize for a such late answer, being absent for a while! You helped me to
   ask the right way. Actually my request targets at a (semantic) validation of
   instance data being loaded or replaced, at a sanity check on input data,
   that is implemented by means of XForms MIPs and event handling.

   As XForms is all about editing and submission of structured, typed and valid data
   I felt it is crucial to ensure that either the data a processor starts to operate
   on confirms to constraints declared by the form author or any sort of (silent) error
   recovery is triggered.

   [1] Use case: form loading external (generated) data and configurations:

     <xf:instance id="config" xmlns="" src="http://myService/servlets/getConfig"/>

   The request populates the instance with data like "<config><code>0</code>...</config>".
   A code different from 0 signals any type of internal error without breaking the data contract.
   One would like to define a validity constraint on this node -

     <xf:bind nodeset="instance('config')/code" constraint= ". = 0"/>

   - and attach a "xforms-invalid" handler to it, called right after the model has been constructed
   (_independent_ of the UI-initialization).

   A workaround hooks into the "xforms-ready" event. Conditional on the invalidity of the
   return code a default configuration is loaded from a different location (static file) :

     <!-- define a condition on semantic validity -->
     <xf:action ev:event="xforms-ready" if="instance('config')/code != 0">
          <xf:message level="modal">failed to load your configuration, using a default setup</xf:message>
          <xf:dispatch name="xforms-submit" target="replaceConfig"/>
     </xf:action>

     <!-- replace the "invalid" instance -->
     <xf:submission id="replaceConfig" ref="instance('config')"
         replace="instance" instance="config" method="get" action="http://myService/defaultConfig.xml"/>

   The form is made accessible only when the underlying data is ensured to be valid:

     <xf:bind id="show" nodeset="instance('config')/code" relevant=".= 0"/>

     <xf:group bind="show">
       ... form ...
     </xf:group>

   [2] Use case: validity controlling form navigation

   Given a wizard like form the author may wish to disable further navigation
   as long as there is invald data detected within the recent page (case).

   Handlers for "xforms-invalid" and "xforms-valid" are used to update a node
   storing IDs of respective invalid nodes and governing the accessibility of
   navigation controls. This approach depends on initial validity notification,
   since there are no functions to query single MIP (like proposed in:
   http://exforms.org/mips.html)

   - - - -

   Are these use cases plausible, they could illustrate following requirements:

    - the need of an "implicit" event handling: events are dispatched also
     to the bind-elements of respective nodes (in addition to their controls).

     Attached handlers are activated in a general way - independent of the existence
     and location of corresponding controls - they rather reflect the recent data state
     and its transitions than respond to explicit changes made by the user. This sort
     of event notification seems to apply especially for hidden nodes (form metadata)
     and calculated values.

    - the need of initial data validation: an XForms-application should apply validity
     checks after loading the instance data.

     As you stated, this request conflicts with the "required-but-empty" problem
     (and thus with the persistent nature of XForms in contrast to stateless single-page
     requests), but an intial validation could be enforeced on singular nodes e.g. by
     setting a flag attribute (defaulting to false) on the bind element:

     <xf:bind nodeset="instance('config')/code" constraint= ". = 0" initialValidation="true"/>


     Best regards
      Jaro









John Boyer schrieb:
> 
> Hi Jaroslav,
> 
> Some answers are inline, surrounded by <jb> </jb>
> 
> Cheers,
> John M. Boyer, Ph.D.
> Senior Technical Staff Member
> 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
> Blog RSS feed: 
> http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
> 
> 
> 
> 
> *Jaroslav Pullmann <pullmann@doctronic.de>*
> Sent by: www-forms-request@w3.org
> 
> 05/14/2008 04:08 AM
> 
> 	
> To
> 	www-forms@w3.org
> cc
> 	
> Subject
> 	validity notification on intial or hidden data
> 
> 
> 	
> 
> 
> 
> 
> 
> 
>  Dear list contributors,
> 
>   in a recent post 
> (http://lists.w3.org/Archives/Public/www-forms/2008Apr/0004.html)
>   the request was mentioned to apply standard form control notification 
> events upon
>   initialization of form controls. Could you please clarify shortly -
> 
>    - will this request become an official requirement for future XForms 
> specs ?
> 
> <jb>
> It's the top agenda item for next week's telecon.
> </jb>
> 
>    - is there currently a way to force the validity notification on 
> initial data
>     (that is not covered by the definition: "an instance data node 
> either changing and
>     being or becoming invalid") ?
> 
> <jb>
> Currently, no.  The desire to get notifications on initialization is 
> well-known to the group though.  Right now, form control initialization 
> is silent. Form controls are expected to initialize themselves according 
> to the information of the model without the model dispatching 
> notifications to them.  If you think about XForms processing as being 
> divided into modules, such as model processing, action processing and UI 
> processing, then the UI processor could, in the future, dispatch an 
> event to signal control initialization.  The context information for the 
> event could contain the bound node and the states of the various MIPs. 
>  But the question arises whether this will satisfy the use cases which 
> cause you to desire the MIP notification events today. It needs further 
> elaboration from the community, so please feel free to describe how you 
> intend to use the MIP notification events on startup and why it is 
> insufficient, as an alternative. to have your implementation query the 
> model for MIP information when it creates a new control.  Finally, note 
> that any solution has to work *any time* a UI control is created, not 
> just when starting up the form.  In particular, the repeat module 
> creates and destroys UI controls often.
> </jb>
> 
>    - why is the notion of "validity" of a instance node bound to its UI 
> control
>      and not to the respective node, instance or a bind element 
> referring to it ?
> 
> <jb>
> The notion of validity is _not_ bound to its UI control.  The notion of 
> validity is associated with actual instance nodes.  The purpose of the 
> model, though, is to inform the UI when things have changed.  When MIPs 
> change, or when a value changes, the MIP notification events are sent to 
> the controls.
> 
> The key to understanding this is to know why the MIP notification events 
> exist.  In their current design, they allow *form authors* to discover 
> changes with which they may want to associate behaviors.  For example, 
> one could run an ephemeral message action when xforms-invalid is 
> received.  They are not designed currently to serve a second purpose of 
> facilitating a particular style of XForms UI processor implementation. 
>  So, currently they are meant as an aid to authors, not implementers.  I 
> suspect the reason you want the events on startup is that you would like 
> an implementation to use the events for some purpose.  Addressing that 
> requirement is on the future feature list, but it's not supported right 
> now.
> </jb>
> 
>   Examples: A (required) node is initialized to an invalid value,
>   no "xforms-invalid" event is triggered preventing any implicit or
>   explicit error recovery or UI adjustment. In contrast the CSS
>   pseudo-classes (:valid, :invalid) are effective and allow
>   to mark the invalid control.
> 
>    Also one would prefer to handle the invalidity of "hidden"
>   (calculated) values by the generic means of event handling,
>   like registering a handler on the instance or a bind element.
> 
> <jb>
> The implementation is expected to show the right thing for required and 
> validity-related MIPs without need of the event.  The form author only 
> hooks the event when something changes.
> 
> This design was especially put in place for form authors to have a 
> convenient way to handle xforms-invalid in XForms 1.0, which did not 
> directly support conditional execution of actions (some actions like 
> setvalue, insert and delete could use XPath predicates in their binding 
> nodes to hack up some conditional behavior, but other actions like 
> message did not define this behavior for simple static messages).
> 
> The problem was that an initially empty template would have many nodes 
> that were "required but empty", which at the time was included in the 
> definition of validity and therefore resulted in an xforms-invalid 
> event.  The concern was that the user would have a very poor experience 
> if the simple act of starting up a form resulted in a ton of 
> xforms-invalid error messages informing the user that the form is not 
> correctly filled out.  The feeling was that the user really needed to 
> get in there and change something before being told that they had done 
> something wrong.
> 
> Put another way, the attempt to associate xforms-invalid with the 
> :invalid pseudoclass is appealing to the implementer, but reduces the 
> utility of the event for form authors by interfering with a pleasant 
> user experience.
> </jb>
> 
> 
>    Many thanks
>    Jaro Pullmann
> 
> 
> 
> 
> -- 
> jaroslav pullmann             d  o  c  t  r  o  n  i  c
> email pullmann@doctronic.de   information publishing + retrieval
> phone +49 228 92 682 00       http://www.doctronic.de 
> <http://www.doctronic.de/>
> 
> doctronic GmbH & Co. KG, Sitz: Bonn, HRA 4685 AG Bonn
> Ust-IdNr.: DE 210 898 186, Komplementaerin:
> doctronic Verwaltungsgesellschaft mbH, Sitz: Bonn, HRB 8926 AG Bonn
> Geschaeftsfuehrer: Holger Floerke, Carsten Oberscheid, Ingo Kueper
> 
> 
> 


-- 
jaroslav pullmann             d  o  c  t  r  o  n  i  c
email pullmann@doctronic.de   information publishing + retrieval
phone +49 228 92 682 00       http://www.doctronic.de

doctronic GmbH & Co. KG, Sitz: Bonn, HRA 4685 AG Bonn
Ust-IdNr.: DE 210 898 186, Komplementaerin:
doctronic Verwaltungsgesellschaft mbH, Sitz: Bonn, HRB 8926 AG Bonn
Geschaeftsfuehrer: Holger Floerke, Carsten Oberscheid, Ingo Kueper

Received on Wednesday, 28 May 2008 11:20:49 UTC