The charter review produced a large volume of comment; to form a manageable summary, this document discusses the process questions raised during the rechartering. A separate document discusses the overall architectural vision behind the chartering of these groups - and how they fit into the wider pattern of the Interaction Domain and the overall Web Architecture.
HTML is one of the most widely used markup languages ever created. Itis natural therefore that its future development should be of interest to a very large number of people. Several steps have been taken to ensure wide participation.
All three Working groups will conduct their technical discussions in public, will encourage widespread public review, and will carefully track comments.
The HTML Working Group Chairs expect to relax good standing requirements, have only two face to face meetings a year, and hold telephone conferences only as needed; all decisions will be taken on a public mailing list as the primary means of specification development.
There is a risk that the lack of face to face meetings and telephone conferences would cause momentum to fail; it is felt that this risk can be managed by strong commitment from the co-chairs to actively maintain forward momentum on the mailing list.
There is also a risk that with fewer face-face meetings, that the trust levels necessary for the collaborative work be weaker. Should the progress of the group reach impasses through a lack of mutual understanding and respect for other views, the decision on face-face meetings may have to be revisited.
There have also been calls to give the document editor or editors ultimate veto power over the working group, essentially making the working group redundant. On investigation, these were motivated by two types of concern:
Worry that the Working Group would consume large amounts of time discussing small details (it being thought that a unilateral decision would cut this short)
Worry that widespread involvement in the document contents would dilute the quality of work.
The first concern should be addressed by capable chairing and issue management. The second is inherent in any public and open process; but widespread public participation should be seen as a strength, not a weakness. Having a single document author accountable only to themselves is both incompatible with standards of fairness and of quality for which the W3C aims, and is not needed to solve the problems mentioned above.
W3C work in parallel on XForms (by the Forms Working Group) and Web Forms 2 (by the Web Application Formats Working group) has resulted in questions on how these two work items interelate. XForms has a solid architectural base, is device independent, accessible, and is also (by design) not upwardly compatible with HTML 4 forms. Web Forms 2 adds some good features but is not compatible with XForms, reinventing some features such as repeat.
Over the last few months, a task force has been working on XForms Transitional (it had other names in an earlier phase but this is the current one, partly motivated by review comments concerning the earlier names). This work draws on XForms, on Web Forms 2, and on other influences. It is intended to be a bridge, using the XForms architecture but compatible with HTML forms - both HTML 4 forms and extended versions.
The proposed charters placed this work in the scope of both the XForms and the HTML Working groups. This was done so that a task force between then could publish Rec-track work that would be within their chartered scope and thus covered by the W3C Patent Policy. the Web Forms 2 work will be moved from the WAF WG and notes as one of the inputs to the Forms taskforce.
Many reviewers of the proposed charters noted an asymmetry - the Forms Working Group was required to work with this task force, but the HTML Working Group was not. This has been corrected, and in the new charters both groups are required to work together in the task force on Forms. The new version of HTML will have improved forms capabilities, and the new version of XForms will gain the ability to process well-formed content conforming to the new HTML forms as well as the original XForms.
In the past, the name of the WG that develops XForms has not been consistently communicated - sometimes Forms, sometimes XForms. The group that develops XForms will be named the Forms Working Group.