Re: Architectural Consistency Requirements for Forms

Got it. Thanks.
 
John




"Weston Ruter" <westonruter@gmail.com> 
Sent by: public-forms-request@w3.org
05/04/2007 01:51 AM

To
John Boyer/CanWest/IBM@IBMCA
cc
"HTML WG" <public-html@w3.org>, public-forms@w3.org, "Maciej Stachowiak" 
<mjs@apple.com>
Subject
Re: Architectural Consistency Requirements for Forms






John,
I meant to direct you to this working test case of the "Repeated rows" 
spec example which you referred to: <
http://weston.ruter.net/projects/repetition-model/testsuite/002.html >

Weston

On 5/4/07, Weston Ruter <westonruter@gmail.com> wrote:
Hi John,

On 5/3/07, John Boyer < boyerj@ca.ibm.com> wrote:

> 1) Observe first off that the template row is not differentiated from 
the data 
> rows, so a poor user experience results when a user deletes the template 

> row since it is no longer possible to add a new empty row. 

This is not accurate. The template cannot be deleted by invoking the 
repetition behavior (see working "planet" example < 
http://weston.ruter.net/projects/repetition-model/testsuite/003.html >). 
The template row is differentiated from the data rows in that its 
repetitionType DOM property is set to REPETITION_TEMPLATE (versus 
REPETITION_BLOCK for the blocks), and furthermore in that the template 
node does not appear in the repetitionBlocks NodeSet. 

> 2) Moreover, if all the rows are deleted, then how does the table ever 
> become non-empty again?   

Again, only the repetition blocks are deleted; the template remains 
intact. The table becomes non-empty by invoking the template's 
addRepetitionBlock method.

> 4) It's also unclear how you'd easily do some kinds of common UI 
constructs 
> like adding a new row relative to where the current focus is located in 
the table 
> or deleting a row with a button that is not in the table row.  Maybe 
these are 
> solvable with current WF2, but they are common enough use cases to 
warrant 
> looking at the markup. 

I agree. I think there should be two more buttons defined for the WF2 
repetition model: add-before and add-after. When these buttons are placed 
within an instantiated template (a block) then they would insert a new 
block in the appropriate location (before and after, respectively). This 
functionality, however, can be scripted currently by passing a refNode 
argument to the addRepetitionBlock method. 

> 5) Finally, the note at the end of nested repeats about the need for 
unicode 
> hacks to bandage the XML non-validity problems seems another symptom of 
> the need for a better solution.. 

I agree. Although perhaps HTML5 should explicitly allow left and right 
square brackets in IDs since it's not XML anyway? :-)

Weston


On 5/3/07, John Boyer <boyerj@ca.ibm.com> wrote:

I think perhaps the most important bit missing from my off-the-cuff 
laundry list is a requirement that I have gotten so used to taking for 
granted that it just didn't float to the top yesterday. 

It's important because it seems to be a bit at odds with some of the 
technical approach taken in WF2, which in turn occurred to optimize a 
seamingly competitive need. 

Frankly, it's expressed in our current charter (
http://www.w3.org/2007/03/forms-charter.html) in the following sentence: 
"It is a goal that this work will be conducted in a task force jointly 
with the HTML WG, draw on the Web Forms 2 work (which moves from the Web 
Application Formats Working Group to the HTML Working Group) and be 
integrated into the XForms architecture (following design principles such 
as the separation of presentation from content)." 

The key is the parenthetic: a foundational tenet of XForms architecture is 
the separation of presentation from content. XForms has tended to optimize 
on this tenet.  Part of WF2 reflects a desire to relax that tenet, and in 
a number of ways the forms working group has expressed amenability to that 
desire. 

WF2 on the other hand seems to optimize on backwards compatibility, which 
no one is arguing against in principle, but it seems in some places to be 
carried to the extreme of avoiding the use of better tags/attributes even 
for net new features for which only limited compatibility with html4 
browsers can ever be hoped for. 

A concrete difference can be seen, for example, with the approach to 
repeating structures.  In XForms a <repeat> expresses the template, and 
the *data* associated with that repeat determines how many instances of 
the template become available at run-time.  In WF2 (
http://www.whatwg.org/specs/web-forms/current-work/#repeatExample ), it is 
shown that the UI controls are repeated in the markup itself as there is 
*no* separation of data and presentation. 

1) Observe first off that the template row is not differentiated from the 
data rows, so a poor user experience results when a user deletes the 
template row since it is no longer possible to add a new empty row.   

2) Moreover, if all the rows are deleted, then how does the table ever 
become non-empty again?   

3) And if "mid-population" data is obtained by an ajax call, you have 
again the problem of not having an empty row template to work with.   

4) It's also unclear how you'd easily do some kinds of common UI 
constructs like adding a new row relative to where the current focus is 
located in the table or deleting a row with a button that is not in the 
table row.  Maybe these are solvable with current WF2, but they are common 
enough use cases to warrant looking at the markup. 

5) Finally, the note at the end of nested repeats about the need for 
unicode hacks to bandage the XML non-validity problems seems another 
symptom of the need for a better solution.. 

What would be better is a technical approach that allows the repeating 
construct to be identified and the template to be specified, but 
prepopulation data should be provided through a separate instance.  It 
also illustrates what we mean by "scale up to XForms architecture" while 
also preserving the most backwards compatibility with html4 that could 
reasonably be expected.  Here is sample of the serialization of the 
planets and moons example from WF2 the way it might look with a good 
separation of presentation and data: 

Presentation: 

<ol> 
   <li> 
      <repeat name="planets"> 
         <label for="name">Planet: </label> <input name="planet" ..../> 
         <h3>Moons</h3> 
         <ul> 
            <repeat name="moons"> 
              <li> <input name="moon" /> <button type="delete">Delete 
moon</button></li> 
            </repeat> 
         </ul> 
         <button type="insert" repeat="moons">Add moon</button> 
      </repeat> 
      <button type="delete">Delete planet</button> 
   </li> 
</ol> 
<button type="insert" repeat="planets">Add planet</button> 

The data model, which is optional if you don't want to prepopulate the 
table, would look like this: 

<form> 
  <instance> 
    <data> 
      <planets> 
        <planet>Mars</planet> 
        <moons> 
           <moon>Phobos</moon> 
           <moon>Deimos</moon> 
        </moons> 
      </planets> 
      <planets> 
        <planet>Neptune</planet> 
        <moons> 
           <moon>Triton</moon> 
           <moon>Nereid</moon> 
           ... 
        </moons> 
      </planets> 
    </data> 
  </instance> 

  <ol> ... from above ... </ol> 
</form> 


The html4 browser sees an empty table and some buttons, which don't work. 
This is expected since html4 browsers won't really understand how to 
operate html5 repeats, so this is about the best that can be expected for 
"backwards compatibility". 

But an html5 browser now has the desired nested table, and at the same 
time all the problems I listed above go away.  The template is clearly 
distinct from the data, so you can't delete the template and you can 
recover from the empty table problem.  It is easy to extend the buttons to 
handle insert/delete at currently focused location because the repeats are 
clearly identified for what they are and don't do double duty as template 
and data.  And the above never resorts to XML invalid content, so it is 
easy to provide "two equal serializations", one XML and the other tag 
soup, that mean the same thing. 

The benefits don't stop there.  Aside from the runt-ime (i.e. the concerns 
of web browser makers), the above separation advantages not only design 
tools that seek to make it easier to author forms, but most importantly 
the authors of and the CPUs that have to run server-side code for 
processing these forms.  For example, it is much easier to write form 
prepopulation code (e.g. a JSP) that just gets some data and drops it in 
one place in the form than it is to write the code that has to generate 
the UI controls to represent that data.  Aside from being easier to write, 
the code is less brittle.  And then there's the tremendously important 
aspect of the lower server load that the separation provides.  The 
transactional volumes required in government to citizen forms applications 
are really critical to consider here. 

I could continue on about the impact of this separation on other language 
features, but this should be enough to exemplify what I see as being 
better "architectural alignment" and to substantiate why it must be done. 

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




Maciej Stachowiak <mjs@apple.com> 
Sent by: public-html-request@w3.org 
05/03/2007 10:51 AM 


To
Maciej Stachowiak <mjs@apple.com> 
cc
HTML WG <public-html@w3.org> 
Subject
Re: Architectural Consistency Requirements for Forms










On May 3, 2007, at 9:13 AM, Maciej Stachowiak wrote:

> John mentioned that these thoughts were off the cuff, and he may 
> have forgotten some important points. I would appreciate it if 
> XForms experts

Oops, I forgot to finish my sentence. "I would appreciate it if 
XForms experts would mention any requirements they think should be 
added to this list."

Regards,
Maciej