View source for PF/XTech/HTML5/Forms/FormsRequirements

__NOTOC__
= Forms Requirements for HTML5 =

== Feedback Provided to HTML Working Group by GJR, 10 July 2008 ==

The Forms WG's effort in drafting [http://lists.w3.org/Archives/Public/public-forms/2008Mar/0097.html XForms 1.2, Transitional] to explicitly accomodate syntactic expressions, and its extension of the XForms processing model, has lead to the adoption of as much of Web Forms 2 as possible in order to: (a) provide streamlined form-construction for web authors and authoring tool developers; and (b) to provide an on-ramp for web authors who will need to scale up to XForms so that their frontplane integrates seamlessly with their backplane. What is needed, therefore, is for Web Forms 2 to be as flexible about syntax-level changes as the Forms WG has been in producing XForms 1.2 Transitional, so that a single solution renders XForms and WF2 "extensions" of each other.  This will lay the foundation for a new single architectural construct from the point of view of web authors. "Architectural alignment" between XForms and Web Forms, '''''must not''''' be reduced simply to the ability to satisfy a mutual set of use cases. True "architectural alignment" is only possible if the Forms WG and the HTML WG can cooperate as two working groups producing a '''''single''''' construct: next-generation web forms which the community can readily adapt, use, and deploy, through a common client-side processing model.

Therefore, this web resource documents my '''strong''' agreement with the ''Architecture of Forms'' principles outlined and annotated by [http://lists.w3.org/Archives/Public/public-forms/2008Apr/0068.html John Boyer in his post to public-forms of 10 April 2008]. They are presented here in their abstracted form:

# The forms vocabulary '''''must''''' leverage terms from [http://www.w3.org/TR/ 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.
# The forms vocabulary '''''must''''' allow a seamless mapping from a conceptual single-layer authoring style to the model-view-controller-submission architecture of XForms.
# The forms vocabulary '''''must''''' allow the use of terms familiar to today's web authors for the conceptual single-layer authoring style
# 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.
# The forms vocabulary '''''must''''' allow incremental author opt-in of the key components and processing models of XForms as they are needed.
# The forms vocabulary '''''must''''' allow a named form control to be synonymous with the datum it collects, thereby implying a data layer.
# The forms vocabulary '''''must''''' allow the data layer to be hierarchic based on hierarchy expressed in the user interface.
# The forms vocabulary '''''must''''' allow simple declarative [http://www.w3.org/TR/xpath XPath expressions] for dynamic data value and property calculations.
# 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.
# The forms vocabulary '''''must''''' allow dynamic change to the presentation via mutation of the data layer.
#* any dynamic change caused by a mutation event '''''must''''' be communicated programmatically to assistive technologies, and should obey the "politeness" levels defined in [http://www.w3.org/WAI/PF/group/aria ARIA 1.0]; ARIA should '''''not''''' be relied on as a crutch, as a native solution is not only superior, but essential for some user groups
# The forms vocabulary terms '''''must''''' work in HTML with '''''no''''' namespace qualification.

== Unresolved Questions and Issues on HTML Forms ==

# Will HTML5 absorb the section on Forms into the main draft, or will Web Forms 2.0 or XForms 1.2 Transitional be allowed to become modules that can be plugged-into HTML5?
# The question of extensibility remains, regardless of the results of the [http://www.w3.org/2002/09/wbs/40318/wfreq/results formal survey on Web Forms]; will [http://www.w3.org/html/wg/html5 HTML5] '''''and''''' the XML serialization of HTML5 allow for use of XForms 1.2 Transitional, straight [http://www.w3.org/TR/2007/REC-xforms-20071029/ XForms 1.0 (Third Edition)] or [http://www.w3.org/TR/xforms11/ XForms 1.1], or [http://www.w3.org/TR/web-forms-2/ Web Forms 2.0], depending upon the author's inclination and target audience (from both the backplane and end-user points-of-view)?

----
== Other Considerations ==

* [http://code.google.com/p/ubiquity-xforms/ Ubiquity Library for XForms]: a standard library to enable XForms functionality without a plugin

----
* [[PF/XTech/HTML5| HTML5 Issue Collection and Requirements Drafting Index]]
* [[PF/XTech| XTech Wiki: Issues Which Cut Across Specific Working Groups & Domains]]
* [http://www.w3.org/WAI/PF/group PF Working Group Member-Confidential Space]
* [http://www.w3.org/WAI/PF/ PF Working Group Public Web Space]