Big update to XForms 1.1 spec; Ready for your review

Dear Working Group Members,

Due to the struggles we have long been having with certain issues as well 
as the need to address certain last call comments, I felt it was necessary 
to do a much better job of specifying certain pervasive concepts in 
XForms.  My hope was to really try to help "take us to the next level" of 
rigor in order to make it easier to fully implement 1.1 as well as figure 
out how to add more features in 1.2 and 2.0.

Luckily I get to run for the hills for two weeks while you decide how you 
feel about the new content.  But seriously, I've really put a lot of work 
into this, and I think you will like the results (even if you don't agree 
with every last detail of it :-). 

Please see the "editor's draft" diff-marked version here: 
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html

Here are the important types of changes that I made that you should be 
looking for:

1) FORM CONTROLS 

I created definitions for "core form controls" (the things in chapter 8 
that provide UI points of direct interaction with the end-user) and 
"container form control" (the group, switch and repeat objects in Chapter 
9).  This allowed me to define "form control" as the union of the two. 

In turn, these definitions required me to hunt down all 315 occurrences of 
form control and make sure it was being used correctly.  See in particular 
the Processing Model chapter, which contains descriptions of all our 
events.  The ones targetted at "form controls" in the past had to be 
looked at carefully to define what the real targets should be.

This was really necessary in order for me to fix things like describing 
what it means to set the focus to a container form control, which is a 
last call comment.


2) REPEAT PROCESSING/EVENT FLOW IN REPEATED CONTENT

This one is the mother lode.
It really started with incorporating Uli's changes to get rid of 
"homogeneous collection".  He did a great job of switching over to "repeat 
collection".

It inspired me to rigorously define "repeat item" as node from the 
collection, its position and size and a "repeat object", which was defined 
as a group element that contains a set of run-time objects created from a 
repeat template.

This made it easy to say "set the focus to a repeat object" and mean set 
the focus to a group representing the set of controls, and then setting 
the focus to a group (or switch) can be defined as automatically handing 
focus to a contained control.

Anyway, the "run-time objects" were defined as being actual form controls 
so that it was clear you could really dispatch events to them.  And having 
the repeat object be an actual group made it easy to describe the XML 
eventing *within* the repeat object.

All of these definitions made it much easier to describe the run-time 
mutation of a repeat to add or remove repeat items by various means, 
including insert/delete, instance replacement and even by use of setvalue 
(in the case where the repeat nodeset contains dynamic predicates).

Armed with that, it was possible to describe repeat updating and index 
manipulation on insert and delete as behaviors related to xforms-insert 
and xforms-delete events.  Along the way, the inner repeat index 
reinitialization cruft was, of course, removed (retaining deletion diff 
marks and added notes to ensure it was clear the behavior does not 
happen).

Finally, that allowed me to move the insert and delete actions out of the 
repeat module and into Chapter 10 Actions.  Of course, toggle and setindex 
followed, even though they are classified as actions that are specific to 
their respective modules, the point remains that ALL XForms actions are 
now in Chapter 10 (just as all submission information is now comfortably 
in Chapter 11).


3) MIP ENFORCEMENT

I wrote diffs into all MIPs in Section 6 to explain the fact that they do 
not impede the behavior of actions.
Although I provided good reasons why this is true, the points in Erik's 
recent mail are even better than my own.  Faced with this growing mound of 
irrefutable arguments, it seemed appropriate to show you what the result 
looks like in spec-ready text.
This is related to the recent discussion about the readonly MIP, but the 
issue is applicable to all MIPs


4) REMOVED "first text node" BEHAVIOR (per action item)

Went through all the form controls to draw peoples attention back to the 
common processing rules for form controls, and in particular to clearly 
call out in each form control that it should fail with binding exception 
if it is supposed to bind to simpleContent.

Then, defined exact behavior of binding to an element as reading the 
string of it and writing to it in such a way that it only has one child 
text node left if the string being written is non-empty OR zero child text 
nodes if the string is empty. 

While at it, I noticed that an unrelated problems happens with the xpath 
data model if you bind directly to a text node and then write the empty 
string.  The node goes away according to XPath.  I called it out because 
it's true, but I'm sure it will make for some discussion. 

5) FIXED OTHER SMALL ISSUES

For insert and delete, the context attribute now applies even if you use a 
bind for the nodeset binding.  That was easy, and it makes a lot more 
sense.

Fixed small problem I introduced in insert a couple weeks ago while 
accounting for the "root node" of XPath (the parent of the root element).

Moved the DOM interface and hasFeature sections from Chapter 7 to the end 
of Chapter 4.

Did all the latest fixes to choose() that we recently agreed upon, and I 
moved by choose() and event() to a new subsection for "Object Functions"

Pointed out in implementation requirements for element input that the user 
should be prevented from entering multiline text (since that's what 
textarea is for)

Well, that's the bulk of what I can remember doing, anyway.

See you in  a few weeks...

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