Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XEP-0004: Empty and absent values #1387

Merged
merged 1 commit into from
Sep 18, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions xep-0004.xml
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Expand Down Expand Up @@ -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>
Expand Down