More progress needed today on Forms TF

Hi guys,

I think a more in-depth response is needed than the one you sent earlier.

The response from Anne basically asks for a response to Maciej's posting 
here: 

[1]<http://lists.w3.org/Archives/Public/public-forms-tf/2008Apr/0017.html>

I think it is fair for them to ask you to take it up a level and have the 
discussion about what is really trying to be achieved by mapping what we 
are doing to the points in Maciej's email as well as pointing out things 
that are missing (which he did ask for).

Please see the following link for some additional material that could be 
used in response: 

[2] http://lists.w3.org/Archives/Public/public-forms/2008Apr/0068.html

For starters, I think that [1] goes off the tracks at the very beginning 
by wanted to constrain the discussion to what version of "architectural 
consistency" should be considered.  This angle seems to be bent around 
turf protection for WGs or implementers rather than getting a deep 
integration by two working groups that want to serve a common customer, 
the web community.

The TF needs to focus on how to best serve the web community, not make the 
shallowest possible concept mapping that permits further siloed 
development of technologies that will be seen as disparate by the web 
community.  I think it is telling at the end of [1] it is claimed that 
XHTML and SVG are the same according to almost all of the "architectural 
consistency" guidelines in [1].  That is the level of architectural 
consistency that is convenient for siloed implementation but a grave 
disservice to open standards and the web community they serve.

It is time for one of you to take up the leadership position and say so.

I think it is time to say that you think we should start with his #8.  It 
is not too strong a requirement to have the same processing model and in 
fact that is exactly what we think is achievable by the work we are doing 
in XForms 1.2 "streamlined for web authors".  Then, you should take it a 
step further and say that #4 is not only reasonable but quite important to 
web authors.  No gratuitous difference please!!!  Today's HTML forms have 
a lot of features.  Those should be mappable to the XForms processing 
model.  We are proving that they are. But clearly, we are doing this 
because more features are needed than what is available in today's HTML 
forms.  How do we add them? Well, XForms has the features, so how do we 
bend them into a web author friendly syntax that allows incremental 
adoption and addition of features to the overall *XForms* *client-side* 
processing model?  Gee, seems pretty easy based on a predominantly 
attribute-based approach.  This approach is *consistent* with what the 
HTML WG and What WG people wanted when they proposed WF2.  The difference 
is that we're doing it in a way that *maps* to a common client-side 
processing model because that's part of what we think architectural 
consistency is.

To do this properly, I think you guys are going to have to formulate at 
least one email response every other day.  You say something one day, they 
say something the next, and then you respond the next day after that.  You 
really can't leave this stuff hanging for weeks on end.

Please start with some of the above information and get it out to them. 
But you have to respond in terms of their email as I have done or you 
aren't going to get very far.

Thanks,
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