Re: Fw: XForms 1.2 Design Principles, Forms Architecture

Hi Nick,

The form tag is described as creating an *outer* model.  Any model 
elements *within* it are described as creating inner models to the outer 
model implied by the form tag!?!  This means having the form tag around is 
useful because it is a convenient place to catch events targeted at the 
implied model and implied submission.

We would not necessarily expect to add fieldset, although it wouldn't kill 
us.  At a minimum, HTML5 should be able to attach their fieldset to XForms 
"as if it were an xforms:group" by using the name attribute.

Yes we are saying XPath is the expression language *for declarative 
expressions*.  It is better that these NOT be javascript because we don't 
want to give access to javascript in calculations because javascript 
functions can access the DOM.  However, for lots of expressions, how a web 
author writes them will be easy to understand.  A plus sign is a plus 
sign.  Yes, I do expect there will be violent opposition to this, but the 
reactions to our ideas seem to be binary, so it's just something we have 
to live with and work on.  They will not be able to make the rejection 
based on unavailability of XPath in any real browser, so rejecting the 
idea will ultimately come across as obstructionist.

Finally, as for adding elements we left out on purpose, like fieldset, I 
suppose I can't understand the rationale.  We have the same element that 
does the same thing, only it is spelled differently.  The HTML WG and 
before that WF2 are making the point that these changes of spelling were 
made unnecessarily and they are causing adoption problems for the web 
author community.  Why not support the tag?  To wit, notice that select 
and select1 support optgroup.  Why? 

If there is no compelling reason *not* to support a tag set from HTML, 
then we have to eat our own dogfood here.  We want others to use XForms 
because it has precedence as a W3C recommendation, so we have to be 
willing to bend a bit and support the reasonable tag names that set 
precedents for us.  Tags like fieldset, option, optgroup and even label 
don't seem unreasonable. 

In fact, it is interesting to note that our table creation story via 
repeat does leave a few things to be desired because we have nothing more 
intelligent than repeat to bind together all the other things needed to 
really make a table.  It seems to me that whatever we come up with should 
borrow as much as possible from HTML table which, in combination with 
xforms repeat, could be a very powerful tool.  I would expect, for 
example, that at least HTML5 authors should be able to use *our* repeat to 
iterate <tr> tags.

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





Nick_Van_den_Bleeken@inventivegroup.com 
Sent by: public-forms-request@w3.org
04/15/2008 02:32 AM

To
XForms <public-forms@w3c.org>
cc

Subject
Fw: XForms 1.2 Design Principles, Forms Architecture







I noticed that I forgot to copy this e-mail to the list.... 

Nick Van den Bleeken  -  Research & Development Manager
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivegroup.com 
----- Forwarded by Nick Van den Bleeken/Inventive Group on 04/15/2008 
11:30 AM ----- 
Nick Van den Bleeken/Inventive Group 
04/11/2008 02:57 PM 


To
John Boyer <boyerj@ca.ibm.com> 
cc

Subject
Re: XForms 1.2 Design Principles, Forms ArchitectureLink







Personally I think these guidelines are going o have little chance of 
getting accepted by all the members of the Forms TF because, as I read it 
XForms adopts the name attribute, the form element and therefore HTML 
forms needs to have XPath as its expression language, and ... 

The more I think about our current approach to import html-form elements 
into XForms the more I get doubts about it : 

We are thinking (or have decided) to import the form element which is 
conceptually an XForms model. This has some disadvantages : 
  1. Event flowing : The form element is currently described as creating 
an inner model in the default model. If you explicitly add the default 
XForms model element the form element isn't a child element of the model 
but I guess you want the event to capture/bubble from the default model to 
the inner model. But this doesn't work, because the form-element is not a 
child element from the default model element. 
  2. Single root: The advantage of XForms is that when you have two forms 
on one page (i.e. two models) you can hierarchically interchange the 
elements/controls from the two models 

In XForms we have the group element (with label), in HTML forms they use 
fieldset (with legend) to group controls. Are we going to add the fieldset 
element to group controls to Core XForms too? 

Don't understand me wrong, the addition of the name attribute (named 
binds, other in-line evaluation context) is great, it adds real 
functionality to the XForms language. But adding elements that were left 
out on purpose because they were replaced by better constructs is a bit 
strange for me. What about the idea of creating a module 'XForms for HTML 
Form authors' that just defines how those elements map to Core XForms. 
Over time we can migrate those features to Core XForms if we think that 
they are an improvement to the Core language. 


I know that this response is a bit high level, and not concrete. But I 
will respond in more detail after the group has had time to respond to 
this e-mail. 

Regards, 

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

public-forms-request@w3.org wrote on 04/11/2008 02:44:55 AM:

> 
> To feed the Forms Joint Task Force discussion on "Architecture of 
> Forms", I think it makes sense to succinctly state the principles 
> that are guiding the design of the XForms 1.2 syntax.  This is only 
> my take on it, and I hope this can be honed and refined through 
> group discussion this week and early next week so we can send 
> something like this out to the task force later next week. 
> 
> 
> 1) The same forms vocabulary must be expressible in XML syntax and a
> non-XML web syntax. 
> 
> 
> 2) 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. 
> 
> 
> 3) The forms vocabulary must allow a seamless mapping from a 
> conceptual single-layer authoring style to the model-view-
> controller-submission architecture of XForms. 
> 
> This is the fundamental goal of the task force communicated in the 
> WG charters as well as being another way of saying principles #1 and #2. 

> 
> 
> 4) The forms vocabulary must allow the use of terms familiar to 
> today's web authors for the conceptual single-layer authoring style. 
> 
> This is a facet of principle #2 as applied to the HTML Recommendation. 
> 
> 
> 5) 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. 
> 
> For example, a named div in HTML corresponds to a named group in 
> XForms vocabulary.  This is necessary because of the precedence of 
> div in the W3C HTML Recommendation (principle #1).  However, this is
> not intended to allow new feature creation with terms that ignore 
> obvious existing terms in other recommendations like XForms (principle 
#2). 
> 
> 
> 6) The forms vocabulary must allow incremental author opt-in of the 
> key components and processing models of XForms as they are needed. 
> 
> This is a facet of principle #2 as applied to XForms. 
> 
> 6a) instance for declaring a block of XML. 
> 6b) submission once server communication of XML data is needed 
> during form execution 
> 6c) bind for declaring calculations of data values and properties on
> declared blocks of XML 
> 6d) Single node binding attributes (e.g. ref) for attaching form 
> controls to declared XML data 
> 6e) Access to setvalue, insert and delete as actions and as DOM 
> script functions as data manipulation needs arise 
> 6f) group as form control aggregation needs arise 
> 6g) repeat and setindex as row-based content duplication needs arise 
> 6h) switch and toggle as conditional content needs arise 
> 6i) output as display needs arise for calculated results or declared XML 
data
> 6j) other controls such as select1, trigger, submit as the needs for
> their semantics arise 
> 
> 
> 7) The forms vocabulary must allow a named form control to be 
> synonymous with the datum it collects, thereby implying a data layer. 
> 
> This is an aspect of principle #3. 
> 
> 7a) In order to imply a data layer, there must be a containment 
> element to define the collection of controls included in the data 
> layer.  Due to principle #2 and #4, this must be the form tag. 
> 7b) A means of naming the form controls is needed.  Due to principle
> #2 as applied to HTML, this needs to be the 'name' attribute. 
> 
> 
> 8) The forms vocabulary must allow the data layer to be hierarchic 
> based on hierarchy expressed in the user interface. 
> 
> 8a) It must be possible to express simple hierarchy with a named 
> group element. 
> 8b) It must be possible to express conditional hierarchic content 
> with a named switch element. 
> 8c) It must be possible to express repeated hierarchic content with 
> a named repeat element. 
> 8d) It must be possible for data hierarchy to be implied by the name
> attribute so that HTML to use other grouping elements like div. 
> 
> 
> 9) The forms vocabulary must allow simple declarative XPath 
> expressions for dynamic data value and property calculations. 
> 
> 9a) The expressions must be able to access the data layer using a 
> simple XPath variable syntax that maintains the flat model 
> conceptualization familiar to web authors 
> 9b) The expressions must be able to access the data layer using 
> simple XPath location paths that follow the structure of the user 
> interface.  An expression in a form control attribute must be able 
> to access the value of a sibling form control with a location path 
> containing zero slashes. 
> 9c) Aside from the XForms precedence of using XPath for these 
> expressions (principle #2), XPath is used in lieu of javascript 
> because it avoids conflicts arising from ability to mutate the DOM 
> with javascript functions, which conflicts with the intent of the 
> declarative calculation system. 
> 
> 
> 10) 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. 
> 
> 10a) An attribute called "calculate" must be used to express an 
> XPath for the value of the datum (and hence the form control). 
> 10b) An attribute called "relevant" must be used to express an XPath
> for whether the data and form control are suitable for rendition 
andsubmission
> 10c) An attribute called "readonly" must be used to express an XPath
> for whether the data is modifiable.  For compatibility, the special 
> keywords 'readonly' and 'true' must be recognized before 
> interpreting the attribute content as an XPath 
> 10d) An attribute called "datatype" must be used to associate an 
> XForms or XML schema datatype with the data of the form control. 
> This attribute is mapped to the "type" attribute from XForms, but 
> the name "datatype" is used due to the use of preceding use of 
> "type" in HTML form controls. 
> 
> 
> 11) The forms vocabulary must allow dynamic change to the 
> presentation via mutation of the data layer. 
> 
> 11a) The data manipulation actions of XForms (insert, delete, 
> setvalue) must be exposed to Javascript with sensible parameter 
> defaults that keep authoring simple and based on the names 
> established by the name attribute on form controls. 
> 11b) It must also be possible to express mutations as declarative 
> form control event handlers. 
> 11c) It must be possible to express dynamic interactive web 
> applications without explicit use of javascript. 
> 
> 
> 12) The forms vocabulary terms must work in HTML with no namespace 
> qualification. 
> 
> 12a) Attributes derived from XML events must be imported, especially
> event, target and phase. 
> 12b) Elements and attributes from XForms must be imported. 
> 12c) The null namespace must automatically used for the implied data 
layer 
> 12d) The instance element from XForms needs work to ensure that 
> unqualified data content is regarded as being in the empty namespace. 
> 
> 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
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer