Discussion points for "Forms-A"

1) In the last 10 minutes of the face-to-face, the issue of the name 
"WebForms-A", versus "Forms-A", was raised.  Discretion being the better 
part of valor, I Iet the matter go at the time because we had the imminent 
possibility of exposure of the document at the tech plenary, and some 
concern expressed about the name possibly vexing certain parties. However, 
I do still want to circle back to having a discussion about that name 
because I think it is a mistake to call it anything other than WebForms-A.

The W3C is that organization whose mission is to "lead the *web* to its 
full potential".

We are the Forms working group *within the W3C*.

Our mission is to define the "next generation of forms *for the web*".

I do not believe it is belligerent or provocative to call our work what it 
is.  WebForms-A is a way to impart next generation forms functionality to 
web pages with an attribute decoration methodology.  I think we are overly 
worried about vexing others who, on the one hand have not shown us the 
same consideration, and who on the other hand will have every reason to 
absorb our work on "WebForms-A" into the HTML/Forms task force and use it 
as the next generation of what is currently called "WebForms 2.0". 

Put another way, if there is going to be a mending of the rift at all, it 
is probably going to get called WebForms-A anyway.  We *have* to drive 
adoption of our technology, and calling it other than "WebForms-A" goes 
beyond issues of appeasement and nice-guys-finish-last and right down to 
just being a suboptimal marketing decision for our wares in the real 
world. 


2) Now that the whole calculation system is fleshed out, that whole idea 
of doing an "XPath variable" version in which names at multiple levels 
could be accessed by XPath variables rather than using XPath just seems 
like a whole lot of unnecessary complexity to add, both for implementation 
and for understandability.  It's nice that documents become more tolerant 
to significant structural changes using variables, but... are we sure that 
couldn't be an add-on for a future version.  I really don't want to go so 
far down the path of complexity that we chase off the people at whom this 
is ultimately targeted.


3) Note that label, hint, help and alert look like they should be 
attributes in Forms-A (an attribute decoration module).  This makes a lot 
of sense, and still allows one to scale up to our element level modules 
later.


4) The addition of simple increase() and decrease() operations for repeat 
form controls has allowed me to defer the whole issue of XForms actions 
(e.g. setvalue) to the "incremental adoption" chapter.  I think we'll 
probably need to add a "set()" operation to all form controls, but 
otherwise, the full value of insert and delete as well as other actions 
like setfocus and setindex can be left to incremental xforms adoption

Let's get some threads going for these points, and others you may think 
of.

Thanks.
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
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