<p>Now that &xep0004; has been finalized, several uses of jabber:x:data forms have been put on the standards track, including &xep0045;. These protocols typically need a way to gather data from both humans (using a GUI format) and computer processes (using a pre-defined but flexible format).</p>
<p>The 'jabber:x:data' namespace provides an adequate mechanism for both of these uses, as long as computer processes can rely on the var="" names on a particular type of form.</p>
<p>This document proposes a specific mechanism for the ®ISTRAR; to standardize these form field variable names. Thus this document enables existing clients to process forms as they have to this point, but enables protocol authors to specify a mechanism for non-GUI processors of those forms to determine the semantic meanings of those forms.</p>
<li>Forms must continue to be presentable to humans for data entry.</li>
<li>Jabber clients that know how to process generic jabber:x:data messages must be supported; the basic format of jabber:x:data must not change.</li>
<li>If a form type is used in the context of a standards-track protocol, it should be standardized and registered; however, there is no requirement that all form types must be registered (e.g., form types used in custom applications).</li>
<li>If a form type is standardized and registered, field names used in the context of that form type must either be standardized as well or else be clearly labeled as unregistered.</li>
<li>Forms that are not directed <em>to</em> an entity must be able to traverse the entity (e.g., a form sent to a MUC room, intended for the participants of the room, and not the room itself).</li>
<li>Forms must continue to be flexible for implementations; unknown future expansion fields must not be limited.</li>
<li>The chosen approach must work for forms embedded in messages as well as in IQs.</li>
<p>Within Jabber, namespaces are used to scope data that conforms to a schema (often data that extends the core protocol in some fashion). In addition, namespaces can also provide context for the field variable names used in jabber:x:data forms and reports. This proposal makes that link explicit by defining a mechanism for linking a namespace name with a form and the field names and types used in that form. Specifically, the namespace name is specified in the form as the value of a hidden variable called "FORM_TYPE".</p>
</section2>
<section2topic='Whether to Register'anchor='approach-register'>
<p>If the FORM_TYPE is not registered, the field MAY have any name (managed by the namespace owner).</p>
<pclass='box'>Note: Older versions of this specification mandated that unregistered field names had to begin with the prefix "x-". In accordance with &xdash;, that mandate has been removed.</p>
<p>In the following example, the FORM_TYPE is 'http://jabber.org/protocol/pubsub', all of the fields whose names start with "pubsub#" are registered with the XMPP Registrar (see &xep0060;), and the custom "time_restrictions" field defined by the organization at example.com uses &clark; in the field name.</p>
<p>If the FORM_TYPE field is not type="hidden", it does not have the special meaning defined herein.</p>
<p>If the form is used in an IQ, the namespace of the <query/> element SHOULD match the base namespace of the FORM_TYPE. (One possible way of solving this problem would have been to reuse the <query/> tag from the IQ form of jabber:x:data within messages, but that would have meant that existing clients would not have been able to participate in these exchanges.)</p>
<p>The registrant MAY register more than one FORM_TYPE at a time, each contained in a separate <form_type/> element. The registrant MAY also register more than one field at a time, each contained in a separate <field/> child element. Registrations of new fields within an existing FORM_TYPE MUST include the full XML snippet but SHOULD NOT include the FORM_TYPE description (only the name and the XEP number or other document identifier). Note that for ease of use the format for the <field/> element in the registry submission is the same as that defined in XEP-0004; in addition, the value of the 'type' attribute MUST be one of those defined in that XEP-0004.</p>
<p>In addition, a registrant MAY also register particular field option values for fields of type 'list-single' and 'list-multi'. The format for such submissions is as follows:</p>
<code><