XEP-0004: Empty and absent values

The pre-existing specification does not differentiate between empty or absent values. As the XEP has reached the 'final' status, such definitions can not be added to this XEP now.

This commit doesn't (intend to) add new definitions. It merely documents consequences of what is the current final spec.

The intention of this change is to make explicit that users of this XEP cannot expect this distinction to be present (unless it is explicitly defined in dependant XEPs). As a result implementations can be expected to use a variety of representations.

xep-0004.xml

@@ -28,6 +28,12 @@
     &jer;
     &temas;
     &stpeter;
+    <revision>
+      <version>2.13.2</version>
+      <date>2024-08-30</date>
+      <initials>gk</initials>
+      <remark><p>Add section on empty and absent values.</p></remark>
+    </revision>
     <revision>
       <version>2.13.1</version>
       <date>2022-07-25</date>
@@ -357,6 +363,10 @@
   <section2 topic='Incomplete Submission Form Handling' anchor='incomplete-submission-form-handling'>
     <p>An incomplete submission form is a data form of the type "submit" that contains all required fields but some optional fields are omitted. The receiving entity of an incomplete submission form SHOULD only process (e.g., apply) the submitted fields. If applicable, the values of the omitted fields SHOULD keep their current value. The current value is often the value found in the corresponding form of the type "form".</p>
   </section2>
+  <section2 topic='Setting empty or absent values' anchor='empty-or-absent-values'>
+    <p>As specified in the previous section, the values of the omitted fields SHOULD keep their current value. From this, it follows that 'unsetting' a field value requires a request to contain a &lt;field/&gt; element.</p>
+    <p>This XEP does not standardize a way to differentiate between an "empty" and "absent" value. Unless other XEPs explicitly define these semantics, implementations can be expected to use a variety of representations, such as &lt;field&gt;&lt;value/&gt;&lt;/field&gt; or &lt;field/&gt; to signal the absence of a (non-empty) value.</p>
+  </section2>
 </section1>
 <section1 topic='Data Validation' anchor='validation'>
   <p>Data validation is the responsibility of the form-processing entity (commonly a server, service, or bot) rather than the form-submitting entity (commonly a client controlled by a human user). This helps to meet the requirement for keeping client implementations simple. If the form-processing entity determines that the data provided is not valid, it SHOULD return a "Not Acceptable" error, optionally providing a textual explanation in the XMPP &lt;text/&gt; element or an application-specific child element that identifies the problem (see &xep0086; for information about mappings and formats).</p>