W3C home > Mailing lists > Public > public-forms-tf@w3.org > June 2008

Re: Status update

From: Keith Wells <wellsk@us.ibm.com>
Date: Mon, 2 Jun 2008 14:43:28 -0400
To: public-forms-tf@w3.org, public-forms-tf-request@w3.org
Cc: "Anne van Kesteren" <annevk@opera.com>, Nick_Van_den_Bleeken@inventivegroup.com
Message-ID: <OF49FAEF33.E842A1B8-ON8725745C.004ED1A1-8525745C.0066D908@us.ibm.com>

The  XForms WG and HTML WG  should focus on the web community, and
“Architectural Consistency” should be for the convenience of the web
community at-large and not necessarily for the convenience of Standards
writers.  “Architectural Consistency”, seemingly the primary concern of
this task force, should be defined as well-thought-out,  foundational and
unambiguous open standards.

As Nick and earlier appends have stated, the XForms Working group is
streamlining  XForms 1.2 for web authors.  XForms has the features needed
for today's HTML forms, features in HTML which do not exist today, and we
are working to map these features into web author friendly syntax to allow
incremental adoption and addition of features to the overall  "XForms
Client-Side" processing model.  But more, we believe that folding in XForms
features along with  this streamlined approach to HTML are architecturally
consistent with  a "Common Client-Side" processing model.  Isn't this the
goal for this TF?

It is our hope that these guidelines for the design of the XForms 1.2
syntax  brings Maciej's comments[1] into clearer focus for this TF to

   The forms vocabulary must leverage terms from W3C Recommendations where
   it is possible to do so in lieu of new terms.  Simple extensions to
   existing terms must take priority over new terms.
   The forms vocabulary must allow a seamless mapping from a conceptual
   single-layer authoring style to the model-view-controller-submission
   architecture of XForms.
   The forms vocabulary must allow the use of terms familiar to today's web
   authors for the conceptual single-layer authoring style
   The forms vocabulary must allow the terms that map to the XForms
   architecture to be extended to terms that are unique to the HTML forms
   presentational layer.
   The forms vocabulary must allow incremental author opt-in of the key
   components and processing models of XForms as they are needed.
   The forms vocabulary must allow a named form control to be synonymous
   with the datum it collects, thereby implying a data layer.
   The forms vocabulary must allow the data layer to be hierarchic based on
   hierarchy expressed in the user interface.
   The forms vocabulary must allow simple declarative XPath expressions for
   dynamic data value and property calculations.
   The forms vocabulary must allow properties of a datum to be expressed as
   attributes of the corresponding form control in the conceptual
   single-layer authoring style.
   The forms vocabulary must allow dynamic change to the presentation via
   mutation of the data layer.
   The forms vocabulary terms must work in HTML with no namespace




             p.com                                                      To 
             Sent by:                  "Anne van Kesteren"                 
             public-forms-tf-r         <annevk@opera.com>                  
             equest@w3.org                                              cc 
             05/22/2008 03:27                                      Subject 
             AM                        Re: Status update                   

In principal I agree with the criteria outlined by Maciej.

And personally for me point 4 (Both are reasonably aligned in their
capabilities where they  overlap, without gratuitous differences.) would be
a criteria that I prefer that we (the Forms TF) incorporate in our
'guidelines'. This will ensure that authors  can easily switch between HTML
Forms, XForms and 'WebForms', it will also ensure an that an easy automated
conversion between HTML Forms, XForms and WebForms is possible. And
therefore the XForms WG is looking at a streamlined XForms syntax to see
how feasible this criteria is. I know that this is one of the hardest
criteria in the list but I think we should try satisfy this criteria to
make life easier for the users of our specs.


Nick Van den Bleeken  -  Research & Development Manager
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivegroup.com

 "Anne van Kesteren"                                                       
 Sent by:                                                                  
 public-forms-tf-request@w3.or                                          To 
 g                                      Nick_Van_den_Bleeken@inventivegrou 
                                        p.com, public-forms-tf@w3.org      
 05/21/2008 10:56 PM                                                       
                                        Re: Status update                  

On Wed, 21 May 2008 16:45:06 +0200,
<Nick_Van_den_Bleeken@inventivegroup.com> wrote:
> What do you think about this approach?

I think it would therefore be better if the rest of the Task Force,
especially those who are also a member of the Forms WG, gave input to what

Maciej outlined in April[1] as it seems there's still implicit
disagreement over what we should focus on.


Anne van Kesteren

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Inventive Designers' Email Disclaimer:

This message has been scanned for viruses and
dangerous content, and is believed to be clean.

(image/gif attachment: graycol.gif)

(image/gif attachment: pic11479.gif)

(image/gif attachment: ecblank.gif)

Received on Monday, 2 June 2008 18:44:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:06 UTC